lionsoul2014/ip2region

如果你的 IP 归属地查询必须在本进程内完成、又不想依赖外部地理 API，这个项目值得考虑。核心代价在数据新鲜度：随仓库发布的数据源不按固定周期更新，项目本身也建议对精度要求高的场景改用商业数据。

解决什么问题

服务收到带客户端 IP 的请求，需要在写日志、做路由或内容判断前补上国家、省、市、ISP 信息。调用托管的地理服务意味着每次查询一次网络往返、一个外部依赖和按量计费。改用 ip2region 后，这一步变成对随应用一起分发的 xdb 二进制文件做本地查询：流程不变，但结果来自磁盘或内存，而不是网络。

有什么不同

这个项目由两部分组成：面向多种主流语言的查询客户端，以及用 Go、Java 编写的 xdb 生成程序。同一套 API 同时查询 IPv4 和 IPv6；生成程序会合并相邻 IP 段、对相同地区信息去重压缩，因此不必原样携带庞大的源列表。查询速度上 README 给出三种模式：纯文件查询约 10 微秒；固定 512 KiB 的向量索引缓存减少一次磁盘 IO，平均约 100 微秒；把整个 xdb 载入内存则约为 10 微秒，内存占用等于文件大小。这些是项目自述的数字，并非独立基准测试。

更有意思的是地域字段并不固定为内置的 Country|Province|City|ISP|iso-alpha2-Code，可以追加 GPS 坐标、邮编或业务自定义属性，这让 xdb 更像一套小型 IP 数据管理格式，而不只是查询表。代价在运维侧：构建步骤、文件更新以及自定义字段在各语言绑定间的兼容性都要自己负责。另外内置数据中中国信息为中文、非中国信息为英文，需要统一语言环境时要留意。

谁值得试

适合查询量大、延迟敏感，并且能接受周期性数据刷新流程的后端服务，例如给请求日志补充地区信息，或在已使用 Go、PHP、Java 或其他受支持绑定的应用里做粗粒度地区判断。不适合对 IP 归属地要求实时、权威的产品，例如合规判断或与精确位置绑定的定向投放：README 明确说明仓库内数据源不定期更新，精度要求高、更新频繁的场景建议购买商业离线数据。只偶尔查一次、或无法分发和维护二进制数据文件的团队，应先衡量托管 API 是否更省事。

使用条件与边界

需要目标语言有受支持的查询绑定；若要自建数据库，还需要 Go 或 Java 的 maker。真正的长期约束是数据维护：仓库自带原始数据没有固定更新周期，生产方案必须安排刷新来源，可以来自自有数据，也可以来自购买的数据源。README 给出的是基于「检测算法」的更新思路和视频讲解，而不是现成的自动同步服务，因此多半需要自己编写或改造更新程序。

性能设置也有取舍：512 KiB 索引缓存为固定大小，整文件缓存占用等于数据库体积，而延迟数字是项目自述值。xdb 二进制及其字段布局会成为你存储或序列化边界的一部分；追加字段是受支持的，但你实际使用的绑定必须与 maker 产出的格式一致。

HotRepo 点评

仓库已存在 4013 天，目前只有 2026-10-28 一天的热榜记录：19,774 stars，当日 +22。只有一个可比的日期样本，HotRepo 无法判断关注度是在上升、回落还是持续；这只是快照，不是趋势。作为长期存在的项目，它已有较完整的多语言客户端，但采用前应确认你需要的绑定文档与 maker 构建使用的是同一 xdb 版本并同样说明 IPv6 行为，同时明确数据文件的刷新频率（项目说明）。