简介：这是一套基于PHP实现的IP地址精准定位系统源码，面向需要在地图上直观展示IP归属位置的开发者与学习者。与常见只能定位到市级单位的查询程序不同，该源码可将IP位置精确到百米误差范围内，并借助百度地图接口直接在地图上标注显示，输入IP点击查询即可查看结果，适合用于位置服务演示、网络调试辅助或相关课程实践。资源包共154个文件，以74个png、30个jpg图片素材和21个js脚本、16个css样式文件为主，另含3个php核心文件及若干说明文本，整体约1.52MB，结构完整、便于二次修改。使用前需在js/heightaccapi.js第59行替换为自己的接口。目前已有1405人学习下载，读者可借此了解IP定位与地图接口的整合思路，掌握前端资源组织与后端查询逻辑的配合方式，源码仅供学习交流，使用须遵守法律法规。
1. 从一条日志到一张地图：IP地址精准定位系统到底在解决什么
做后端运维或风控的同行大概率遇到过这种场景：凌晨两点，告警群里弹出一条异常登录日志，只有一行 IP。你需要在十分钟内判断这是内网误报、爬虫扫段，还是真实用户从异地登录。这时候如果手边有一套能跑在自己服务器上的 IP 地址精准定位系统，输入 IP 就能返回国家、省份、城市、运营商、经纬度，甚至能在地图上标出大致位置，排查效率完全是两个量级。
标题里的「IP地址精准定位系统 PHP源码」，本质是一套用 PHP 写的、把 IP 转换成地理位置的查询服务。它通常由三部分组成：一份离线 IP 库（把 IP 段映射到地理信息）、一个 PHP 查询接口（二分查找或前缀树匹配）、一个简单的前端展示页（地图或表格）。它解决的不是「精确到门牌号」这种伪需求，而是「这个 IP 大概在哪个城市、属于哪个运营商」这类工程问题。适合谁？适合中小团队里需要自建风控、日志分析、访问统计，又不想把用户 IP 送到第三方接口的开发者。下面我按自己搭过的一套方案，把选型、建库、查询、排错完整讲一遍。
2. 选型先定死：离线库、在线 API 还是混合方案
2.1 三种数据源的取舍逻辑
做 IP 定位，第一件事不是写代码，而是决定数据从哪来。常见做法有三类：纯离线库、纯在线 API、离线为主在线兜底。纯在线 API 调用简单，但每次查询都要出网，延迟不可控，还有调用量和隐私合规的顾虑；纯离线库把数据落到本地，查询是内存或磁盘操作，毫秒级返回，缺点是库需要定期更新，且精度依赖库的质量。
我一般会选混合方案：日常查询走离线库，离线库查不到（比如新分配的 IP 段）再走在线兜底，并把兜底结果缓存回本地。这样既保证了主链路的稳定和速度，又不会因为库更新滞后而完全失准。对于「精准定位系统」这个标题，离线库是核心，因为只有本地库才能做到「系统」级别的可控。
| 方案 | 延迟 | 隐私 | 维护成本 | 适用场景 |
|---|---|---|---|---|
| 纯离线库 | 毫秒级 | 高，IP 不出服务器 | 需定期更新库文件 | 风控、日志分析、内网服务 |
| 纯在线 API | 几十到几百毫秒 | 低，IP 需外发 | 低，但依赖第三方 | 低频、非敏感查询 |
| 混合方案 | 主链路毫秒级 | 较高 | 中，需维护缓存 | 大多数生产环境 |
2.2 离线库的格式与字段设计
离线库常见格式有纯文本 CSV、二进制 DAT、以及自定义的紧凑二进制格式。CSV 可读性好但查询慢，适合几万条以内；二进制格式查询快，适合百万级以上。我一般会把原始数据整理成两张表：一张是 IP 段表（起始 IP 整数、结束 IP 整数、国家、省、市、运营商、经纬度），一张是索引表（按起始 IP 排序后的偏移）。查询时把 IP 转成整数，在索引表里二分查找。
字段设计上，经纬度建议用浮点数存储，精度保留到小数点后四位即可，再高对城市级定位没有意义。运营商字段建议单独存，因为很多风控规则会按运营商做策略。国家、省、市用统一的编码而不是中文名，避免编码问题，展示时再映射。
-- IP 段表结构，MySQL 示例 CREATE TABLE ip_geo ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, ip_start BIGINT UNSIGNED NOT NULL COMMENT '起始IP转整数', ip_end BIGINT UNSIGNED NOT NULL COMMENT '结束IP转整数', country_code CHAR(2) NOT NULL DEFAULT 'CN', province VARCHAR(32) NOT NULL DEFAULT '', city VARCHAR(32) NOT NULL DEFAULT '', isp VARCHAR(64) NOT NULL DEFAULT '', lat DECIMAL(9,4) NOT NULL DEFAULT 0, lng DECIMAL(9,4) NOT NULL DEFAULT 0, INDEX idx_start (ip_start), INDEX idx_range (ip_start, ip_end) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这段建表语句的关键在于ip_start和ip_end用BIGINT UNSIGNED，因为 IPv4 转整数后最大约 42 亿，超出INT范围。索引建在ip_start上，二分查找时先定位候选行，再用ip_end确认。lat和lng用DECIMAL(9,4)而不是FLOAT，避免浮点误差导致地图偏移。
2.3 为什么不用纯内存数组
有人会问，直接把库读进 PHP 数组，用ip2long后遍历不就行了？小数据量可以，但百万级 IP 段读进内存，PHP 数组的内存开销是数据本身的十几倍，很容易把进程撑爆。我踩过这个坑：一个 80 万行的库，读进数组后单个 PHP-FPM 进程占用超过 400MB，并发一上来就 OOM。后来改成「文件索引 + 二分查找」，内存占用降到几 MB，查询速度反而更稳。所以选型阶段就要把「数据放哪」想清楚，别等上线了再返工。
3. 把 IP 库装进系统：建库、导入与查询接口
3.1 原始数据清洗与 IP 转整数
拿到原始 IP 段数据后，第一步是清洗。常见问题是：起止 IP 有重叠、有空洞、格式不统一（有的带掩码，有的写区间）。我一般写一个 PHP 脚本做预处理，把每条记录转成整数区间，排序后检查重叠，重叠的按「后出现的覆盖先出现的」处理，空洞则记录日志人工确认。
<?php // ip_clean.php 原始数据清洗与整数转换 function ipToInt(string $ip): int { // ip2long 在 32 位系统可能返回负数，用 sprintf 转无符号 $long = ip2long($ip); if ($long === false) { throw new InvalidArgumentException("非法IP: {$ip}"); } return (int) sprintf('%u', $long); } // 假设原始数据每行格式：起始IP,结束IP,国家,省,市,运营商,纬度,经度 $fp = fopen('raw_ip_geo.csv', 'r'); $rows = []; while (($line = fgetcsv($fp)) !== false) { $start = ipToInt(trim($line[0])); $end = ipToInt(trim($line[1])); if ($start > $end) { // 起止颠倒，交换并记日志 [$start, $end] = [$end, $start]; error_log("区间颠倒已修正: {$line[0]}-{$line[1]}"); } $rows[] = [ 'start' => $start, 'end' => $end, 'country' => $line[2], 'province' => $line[3], 'city' => $line[4], 'isp' => $line[5], 'lat' => (float)$line[6], 'lng' => (float)$line[7], ]; } fclose($fp); // 按起始 IP 排序 usort($rows, fn($a, $b) => $a['start'] <=> $b['start']); // 检查重叠 $prevEnd = -1; foreach ($rows as $i => $r) { if ($r['start'] <= $prevEnd) { error_log("重叠区间: 行{$i} start={$r['start']} prevEnd={$prevEnd}"); } $prevEnd = max($prevEnd, $r['end']); } // 输出为紧凑二进制：每条 8+8+2+4+4+4 字节，便于后续快速读取 $out = fopen('ip_geo.bin', 'wb'); foreach ($rows as $r) { fwrite($out, pack('NN', $r['start'], $r['end'])); fwrite($out, pack('a2', $r['country'])); fwrite($out, pack('N', crc32($r['province'] . $r['city'] . $r['isp']))); fwrite($out, pack('f', $r['lat'])); fwrite($out, pack('f', $r['lng'])); } fclose($out); echo "清洗完成，共 " . count($rows) . " 条\n";这段脚本的核心是ipToInt用sprintf('%u')处理 32 位系统下的负数问题，这是 PHP 里一个经典坑。pack('NN')把起止 IP 写成两个 32 位无符号整数，pack('f')写浮点经纬度。输出二进制而不是 CSV，是为了后续查询时可以直接fseek定位，不用解析文本。注意crc32那行是为了把省市区运营商压缩成一个整数，实际项目里我会单独存字符串表，这里为了演示简化了。
3.2 二分查找查询接口
有了二进制库，查询接口就围绕「读文件 + 二分查找」展开。二分查找的边界条件是重点：要找的是最后一个start <= 目标IP的区间，然后检查end >= 目标IP。
<?php // IpLocator.php 基于二进制库的查询类 class IpLocator { private $fp; private $count; private const RECORD_SIZE = 8 + 8 + 2 + 4 + 4 + 4; // 30 字节 public function __construct(string $binFile) { $this->fp = fopen($binFile, 'rb'); if (!$this->fp) { throw new RuntimeException("无法打开IP库: {$binFile}"); } $size = filesize($binFile); $this->count = intdiv($size, self::RECORD_SIZE); } public function locate(string $ip): ?array { $target = (int) sprintf('%u', ip2long($ip)); $low = 0; $high = $this->count - 1; $found = -1; // 二分找最后一个 start <= target while ($low <= $high) { $mid = ($low + $high) >> 1; $this->seek($mid); $data = fread($this->fp, 8); $start = unpack('N', substr($data, 0, 4))[1]; if ($start <= $target) { $found = $mid; $low = $mid + 1; } else { $high = $mid - 1; } } if ($found === -1) { return null; // 比最小 start 还小 } $this->seek($found); $data = fread($this->fp, self::RECORD_SIZE); $start = unpack('N', substr($data, 0, 4))[1]; $end = unpack('N', substr($data, 4, 4))[1]; if ($target > $end) { return null; // 落在空洞里 } $country = substr($data, 8, 2); $hash = unpack('N', substr($data, 10, 4))[1]; $lat = unpack('f', substr($data, 14, 4))[1]; $lng = unpack('f', substr($data, 18, 4))[1]; return [ 'ip' => $ip, 'country' => $country, 'lat' => round($lat, 4), 'lng' => round($lng, 4), 'hash' => $hash, ]; } private function seek(int $index): void { fseek($this->fp, $index * self::RECORD_SIZE); } public function __destruct() { if ($this->fp) { fclose($this->fp); } } }二分查找里$found记录的是「最后一个 start 小于等于目标」的位置，这是关键。如果直接找「等于」会漏掉区间覆盖的情况。seek方法按记录大小偏移，fread只读需要的字节。注意unpack('N')读出来的是无符号 32 位，和写入时的pack('NN')对应。round($lat, 4)保留四位，和建表时的精度一致。这个类每次查询只读两次文件（一次二分中的多次读，一次最终读），实际可以加一层内存缓存热点 IP。
3.3 对外接口与缓存策略
查询类写好后，对外暴露一个 HTTP 接口。我一般用最简单的GET /ip?q=1.2.3.4形式，返回 JSON。为了防止被刷，加一层基于 IP 的限流和结果缓存。
<?php // api.php 对外查询接口 require __DIR__ . '/IpLocator.php'; header('Content-Type: application/json; charset=utf-8'); $ip = $_GET['q'] ?? ''; if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) { http_response_code(400); echo json_encode(['error' => 'invalid ip']); exit; } // 简单文件缓存，按 IP 前两段聚合，减少文件数 $cacheKey = sys_get_temp_dir() . '/ipgeo_' . md5(substr($ip, 0, strrpos($ip, '.'))); if (is_file($cacheKey) && filemtime($cacheKey) > time() - 3600) { echo file_get_contents($cacheKey); exit; } try { $locator = new IpLocator(__DIR__ . '/ip_geo.bin'); $result = $locator->locate($ip); if ($result === null) { $result = ['ip' => $ip, 'country' => 'UNKNOWN', 'lat' => 0, 'lng' => 0]; } $json = json_encode($result, JSON_UNESCAPED_UNICODE); file_put_contents($cacheKey, $json); echo $json; } catch (Throwable $e) { http_response_code(500); echo json_encode(['error' => 'internal error']); error_log($e->getMessage()); }缓存按 IP 前两段聚合，是因为同一 C 段通常属于同一地区，这样缓存命中率高且文件数可控。filemtime判断一小时过期，避免库更新后缓存长期不刷新。注意filter_var只校验 IPv4，如果要做 IPv6 需要另写转换逻辑，这是很多「精准定位系统」源码里被忽略的点——IPv6 的定位精度和 IPv4 差异很大，不能混用同一套库。
4. 避坑与排查：那些让定位结果「飘」的细节
4.1 现象：查询返回空，但 IP 明明存在
原因通常是二分查找的边界写错，或者库文件里存在空洞。排查时先确认目标 IP 转整数后是否落在[min_start, max_end]范围内，再检查二分逻辑是否找的是「最后一个 start <= target」。我见过有人写成找「第一个 start >= target」，结果所有落在区间中段的 IP 都查不到。解决方法是把二分条件改成if ($start <= $target) { $found = $mid; $low = $mid + 1; }，并在最终读记录后加if ($target > $end) return null;。
4.2 现象：定位到城市但经纬度偏移几十公里
这多半是经纬度字段的精度或坐标系问题。原始库可能用的是某种加密坐标系，直接拿去地图上标会偏。解决方法是确认库的坐标系说明，必要时做一次坐标转换。另一个原因是pack('f')写入时用了单精度浮点，精度只有 7 位有效数字，对于经度 116.xxxx 这种值，小数点后第四位可能已经不准。改成pack('d')双精度，记录大小相应调整，查询时用unpack('d')。
4.3 现象：并发一高就 502，CPU 飙满
这是文件 IO 和二分查找次数叠加导致的。每次查询要读 log2(N) 次文件，N 是百万级时约 20 次fseek+fread。高并发下磁盘 IO 成为瓶颈。解决方法是把库加载到共享内存（如 APCu 或 Swoole Table），或者用 Redis 缓存热点 IP 的查询结果。我一般会在IpLocator里加一层 APCu 缓存，key 是 IP 整数，value 是结果数组，命中率能到 80% 以上。
4.4 现象：库更新后查询结果没变
原因是缓存没失效，或者 PHP-FPM 进程里常驻的库文件句柄还指向旧文件。解决方法是更新库时用「写新文件 + 原子重命名」的方式，rename是原子操作，新请求会打开新文件。同时清掉 APCu 和文件缓存。注意不要在更新时直接覆盖原文件，否则正在查询的请求可能读到半截数据。
4.5 现象：内网 IP 被定位到公网地址
ip2long对192.168.x.x、10.x.x.x这类内网地址也会返回整数，如果库里没有对应区间，二分查找可能落到相邻的公网区间上。解决方法是在查询前先判断是否为私有地址，是则直接返回「内网」标记，不查库。私有地址段包括10.0.0.0/8、172.16.0.0/12、192.168.0.0/16，用位运算判断即可。
5. 让定位更稳：从单机到可维护的几个进阶习惯
把系统跑起来只是第一步，真正让它长期可用，靠的是几个不起眼的习惯。第一个习惯是给库文件加版本号和校验。我一般会在二进制文件头部留 16 字节的元信息：4 字节魔数、4 字节版本、4 字节记录数、4 字节 CRC32。查询类启动时先读头部校验，版本不匹配直接拒绝服务，避免新旧库混用导致结果错乱。
第二个习惯是记录「查不到」的 IP。每次返回UNKNOWN时，把 IP 追加到一个日志文件，每周汇总一次，看看是不是库覆盖有缺口。这些缺口往往集中在某些新分配的段或小众运营商，补进去之后定位率会明显提升。这个动作不需要多复杂，一个file_put_contents(..., FILE_APPEND)就够，但坚持做下来，库的质量会越来越贴近自己的业务。
第三个习惯是给查询接口加一个「精度声明」。返回结果里带上accuracy字段，比如city表示城市级、province表示省级、country表示国家级。因为不同 IP 段的定位精度天然不同，有的只能到国家，有的能到城市。前端展示时按精度决定是标点还是标区域，避免用户看到「精确到街道」的错觉。这个字段可以从库的原始数据里带出来，也可以在清洗时按运营商和地区规则打标。
最后一个习惯是定期做回归测试。我会准备一份「已知 IP 列表」，包含各大运营商、常见云厂商、以及自己业务里高频出现的 IP，每次更新库后跑一遍，对比新旧结果。如果某个 IP 的城市从 A 变成 B，就要人工确认是库更新了还是数据出错。这个测试脚本用 PHP 写也就几十行，但能挡住大部分「更新后反而更不准」的翻车。
这套方案我前后迭代过几版，最大的教训是：别一上来就追求「精准到街道」，那既不现实也没必要。把城市级定位做稳，把查不到的情况处理好，把更新流程自动化，比堆一堆花哨功能有用得多。希望帮到你。
本文还有配套的精品资源，点击获取
