链接定位双链路：GPS精准定位与IP归属地兜底实践

做前端和后端的人，大概都接过这种需求：给用户发一条链接，用户点开之后，我们想知道对方大概在哪儿。产品经理嘴上说的是“做个定位”，落到工程上，其实是两条完全不同的链路拼在一起：一条是浏览器提供的 GPS 定位能力，靠卫星和 Wi-Fi 热点指纹算出米级坐标；另一条是服务端拿请求 IP 去查归属地，只能到城市级，但好处是用户什么都不用点，静默就能拿到。这两条链路精度差一到三个数量级，触发条件、失败率、合规要求也完全不一样，很多项目上线后出问题，根子就在于没把它们的边界划清楚——该用 IP 兜底的时候死等 GPS，或者反过来，用户明明授权了精准定位，结果前端还在拿 IP 城市糊弄人。

这篇东西想解决的就是这件事：把“链接定位”拆成两套可落地的技术方案，讲清楚 GPS 定位怎么拿、精度怎么调、坐标系为什么会对不上，IP 地址怎么正确取到真实客户端、归属地库怎么选、误差出在哪里，最后给一套两者拼接的完整实现思路和踩坑清单。适合已经能写接口、能改前端，但在这块还没系统做过的同学；也适合被“定位不准”的线上问题折磨过、想搞清楚到底哪一环出问题的人。代码会给可以直接抄的片段，参数会给选择理由，坑会给排查方向。

1. 先把“链接定位”这件事的边界划清楚

1.1 两套定位能力的精度与适用场景对比

很多人一上来就想着“我要精准定位”，但精准这个词在不同链路里含义天差地别。浏览器 Geolocation API 在移动端并不是单纯读 GPS 芯片，它是操作系统层面的一次融合定位：有卫星信号就用卫星，室内就扫周边 Wi-Fi 热点做指纹匹配，再不行退回基站三角。所以它的实际表现是“室外准、室内飘、地下车库直接超时”。而 IP 归属地是另一套逻辑，它查的是运营商给这个 IP 段分配的注册地，跟你人站在哪儿没有必然关系——你用的是某地办的宽带，人在千里之外出差，IP 归属地照样显示注册城市。

我一般会拿这张表跟产品对齐预期，避免后面扯皮：

看清楚这张表，方案自然就出来了：能用 GPS 的地方优先 GPS，但永远不要让业务逻辑强依赖 GPS 成功。用户拒授权、在地下室、用的老设备、浏览器不支持，这些情况加起来在真实流量里比例不低，我在几个面向普通消费者的项目里观察，首次授权通过率大概在六到八成之间，剩下那部分你必须有一条不需要用户配合的路兜住，否则页面就卡在“定位中”转圈。

这里还有个容易被忽略的点：桌面端和移动端完全是两个世界。桌面浏览器很多根本没有定位硬件，它靠的是 IP 或周边的 Wi-Fi 数据库反查，精度经常是一公里开外，甚至直接返回城市中心点。所以如果你的产品有 PC 端，别指望 GPS 那条链路，老老实实把 IP 兜底做成主路径，UI 上就别写“正在获取您的位置”，写“正在识别您所在城市”更诚实。

1.2 为什么大多数“定位链接”最终靠 IP 兜底

短链、营销落地页、扫码页这类场景，用户是带着目的点进来的，不是来给你授权权限的。浏览器弹出“是否允许获取您的位置”，很多人的第一反应是点“禁止”——尤其是不熟悉这个站点的第一次访问。所以在这些场景里，把 GPS 当主力的设计基本注定失败率高，正确做法是反过来：页面加载先用 IP 把城市定下来，把内容渲染出来，GPS 只作为一个“提升精度”的增强项，用户主动点了“使用当前位置”才触发。

这个顺序还有个实打实的好处：首屏不用等。IP 归属地查询走的是服务端本地库，通常是微秒到毫秒级，完全可以放在页面渲染的同一个请求里带回来，用户看到的就是已经填好的城市。而 GPS 是个异步的、可能耗时十几秒的操作，如果放在首屏阻塞，等于把所有用户的加载体验都拉到一个最慢的分支上。

注意：IP 兜底也有它的假象。移动网络下，同一个出口 IP 可能对应整个地市甚至跨省的用户池，运营商 NAT 之后你看到的 IP 跟用户真实位置可能差出几百公里。所以我从不在业务上把 IP 定位结果当作“用户位置”使用，只当作“默认值”，并且给用户留一个手动改的入口。

另外还有一层现实约束：Geolocation API 只在安全上下文（HTTPS，或者本机地址）下可用。有些老项目还在内网 HTTP 上跑，前端调用直接报错，代码里连 catch 都没有，页面上就静默失效了。这种情况排查起来特别费劲，因为控制台可能只给一行不太显眼的警告。上线前务必确认协议，测试环境用内网 IP 访问的时候记得单独处理。

2. 精准 GPS 定位的实现链路

2.1 Geolocation API 的调用姿势与三个关键参数

标准 API 就三个方法：getCurrentPosition拿一次、watchPosition持续监听、clearWatch停止。看起来简单，但三个配置参数直接决定了你拿到的结果是“秒回但飘”还是“准但慢”：

• enableHighAccuracy：是否请求高精度。设为true时，移动端会优先尝试卫星定位，耗时变长、耗电变多；设为false时系统可能直接给你一个基站或 IP 级别的结果，几百米到几公里。我的建议是首次调用设true，同时把超时压到 8 秒左右，超时后降级到false再试一次，这样既争取了精度，又不会让用户干等。
• timeout：超时毫秒数。不设的话某些实现会等很久。首次建议 8000~10000，降级那次给 5000，总时长控制在 15 秒以内。
• maximumAge：允许使用多久以内的缓存结果。设0表示强制重新定位，设300000表示五分钟内的缓存直接用。页面内多次调用一定要设缓存，否则用户来回切标签页你会把电池榨干。我一般首次0，后续60000。

实际写法我习惯封装成 Promise，顺带把降级逻辑塞进去：

function getPosition(options = {}) { return new Promise((resolve, reject) => { if (!navigator.geolocation) { return reject(new Error('GEOLOCATION_UNSUPPORTED')); } navigator.geolocation.getCurrentPosition(resolve, reject, { enableHighAccuracy: true, timeout: 9000, maximumAge: 0, ...options, }); }); } async function locateWithFallback() { try { return await getPosition(); } catch (err) { if (err.code === 1) throw new Error('PERMISSION_DENIED'); // 超时或位置不可用，降级重试一次 return await getPosition({ enableHighAccuracy: false, timeout: 5000, maximumAge: 60000, }); } }

返回的Position对象里，除了coords.latitude/longitude，coords.accuracy这个字段价值极高——它是系统给出的半径估计，单位米，表示有 68% 概率真实位置落在这个圆内。一定要把这个值带回服务端，因为一个accuracy=8的点和accuracy=3000的点，在业务上根本不是一回事。我们后面做门店核销的时候，就是靠这个值做二次判断：超过 500 米精度的一律不认，提示用户到空旷处重试，而不是直接拒绝。

coords里还有altitude、heading、speed，移动端走路测试时speed还挺准的，但altitude在高楼密集区误差能到几十米，非必要别用。timestamp也别忘了存，排查“用户说他明明在 A 地”这种争议时，时间戳是唯一的证据。

2.2 坐标系对不上：WGS84、GCJ02、BD09 的换算

这是新手最容易栽的坑，也是我见过最多“定位偏了几百米”投诉的来源。浏览器 Geolocation API 返回的是WGS84坐标，也就是国际通用的原始经纬度。而国内主流地图服务在展示时用的是经过非线性偏移的坐标系，两者在国内范围内偏差从几十米到六七百米不等，并且这个偏差不是固定值，是随经纬度变化的。

所以典型的现象是：你从浏览器拿到坐标，拿它去地图上打点，点落到了旁边一条街上；或者算两点直线距离，明明就在同一个商场，算出来 800 米。根本原因从来不是定位不准，而是你拿 WGS84 的数去跟另一套坐标系的底图或 POI 做比对。

常涉及的几套坐标：

工程上的原则很简单：存储统一用 WGS84，只在展示层做转换。数据库里、接口协议里、日志里，全是 WGS84，谁需要什么格式谁自己在最后一公里转。这样将来换地图供应商，你只需要改一个转换函数，不用洗历史数据——洗数据的痛苦我经历过一次，几十万条记录，还得靠抽样比对反推偏移，那活儿干过一次就不想干第二次。

转换算法网上有公开的近似实现，国内范围内误差通常在米级，业务上够用。核心是这么个结构：

const PI = Math.PI; const A = 6378245.0; const EE = 0.00669342162296594323; function transformLat(x, y) { let ret = -100.0 + 2.0 * x + 3.0 * y + 0.2 * y * y + 0.1 * x * y + 0.2 * Math.sqrt(Math.abs(x)); ret += (20.0 * Math.sin(6.0 * x * PI) + 20.0 * Math.sin(2.0 * x * PI)) * 2.0 / 3.0; ret += (20.0 * Math.sin(y * PI) + 40.0 * Math.sin(y / 3.0 * PI)) * 2.0 / 3.0; ret += (160.0 * Math.sin(y / 12.0 * PI) + 320 * Math.sin(y * PI / 30.0)) * 2.0 / 3.0; return ret; } function transformLon(x, y) { let ret = 300.0 + x + 2.0 * y + 0.1 * x * x + 0.1 * x * y + 0.1 * Math.sqrt(Math.abs(x)); ret += (20.0 * Math.sin(6.0 * x * PI) + 20.0 * Math.sin(2.0 * x * PI)) * 2.0 / 3.0; ret += (20.0 * Math.sin(x * PI) + 40.0 * Math.sin(x / 3.0 * PI)) * 2.0 / 3.0; ret += (150.0 * Math.sin(x / 12.0 * PI) + 300.0 * Math.sin(x / 30.0 * PI)) * 2.0 / 3.0; return ret; } function wgs84ToGcj02(lng, lat) { let dLat = transformLat(lng - 105.0, lat - 35.0); let dLon = transformLon(lng - 105.0, lat - 35.0); const radLat = lat / 180.0 * PI; let magic = Math.sin(radLat); magic = 1 - EE * magic * magic; const sqrtMagic = Math.sqrt(magic); dLat = (dLat * 180.0) / ((A * (1 - EE)) / (magic * sqrtMagic) * PI); dLon = (dLon * 180.0) / (A / sqrtMagic * Math.cos(radLat) * PI); return [lng + dLon, lat + dLat]; }

用的时候要注意，这套算法只在特定地理范围内成立，范围外会算出无意义的结果。业务上如果覆盖区域固定，加一个粗略的经纬度包围盒判断就够了，超出范围就原样返回，别硬转。还有一点：反向转换（GCJ02 转回 WGS84）用这个函数做一次近似是可行的，但误差会翻倍，需要高精度就迭代几次逼近，或者干脆依赖服务端库处理，别在前端硬凑。

2.3 权限被拒与精度漂移的处理策略

权限状态在浏览器里是可以通过 Permissions API 查询的，虽然各家实现细节有差异，但至少能区分“还没问过”和“已经被拒绝永久”。这个区别很重要：前者你可以直接弹窗引导，后者你再调 API 也只会立刻失败，反而浪费一次交互机会。

async function checkPermission() { if (!navigator.permissions) return 'unknown'; try { const status = await navigator.permissions.query({ name: 'geolocation' }); return status.state; // 'granted' | 'denied' | 'prompt' } catch (e) { return 'unknown'; } }

状态是denied的时候，正确的做法是静默降级到 IP 定位，同时在页面上留一个不打扰的提示，比如“当前显示的是城市级位置，点击可手动选择”。绝对不要反复弹自定义引导弹窗，那只会把用户赶走。浏览器层面用户拒绝过一次之后，很多实现不会再次弹原生授权框，用户必须去设置里改，这个路径你没法替他走，只能把说明写清楚。

精度漂移的另一个来源是watchPosition的滥用。有人为了“实时更新位置”直接开监听，结果在信号不好的地方收到一连串抖动剧烈的点，地图上的点疯狂跳。我的处理方式是加一层平滑过滤：只有当新点的accuracy优于上一个点，或者两点距离超过一定阈值（比如 30 米）时才更新 UI，其余的点丢掉。这样既保住了响应速度，又不会让界面变成抽搐状态。另外watchPosition一定要在页面隐藏或组件卸载时clearWatch，我见过因为它没清导致页面关了还在耗电的案例，用户投诉手机发烫，查了半天是这一行。

3. IP 地址获取与归属地解析

3.1 怎么拿到真正的客户端 IP

这一步听起来是废话，实际上出错率极高，尤其是在有反向代理、负载均衡、CDN 的环境里。你代码里读request.remote_addr或者req.connection.remoteAddress，拿到的往往是链路上最近一跳的地址——可能是网关的内部 IP，可能是 10 开头的私有地址，也可能是 CDN 节点的出口地址。所有用户都变成同一个 IP，归属地全是一个地方，这种 bug 排查起来很容易被误判成“定位库不准”。

标准的做法是读转发头，但这里有个关键认知：转发头是可以被客户端伪造的。X-Forwarded-For是一个用逗号分隔的列表，每一跳代理往后面追加一个地址。如果客户端自己带了一个假的X-Forwarded-For: 1.2.3.4，你的代理再追加，你拿到的是1.2.3.4, 真实IP。这时候取最左边那个就错了。

正确的逻辑是从右往左数，跳过你信任的代理层数：

def get_client_ip(headers, remote_addr, trusted_hops=1): xff = headers.get('x-forwarded-for') if xff: parts = [p.strip() for p in xff.split(',') if p.strip()] if parts: # 从右侧数，跳过 trusted_hops 层可信代理 idx = len(parts) - trusted_hops if idx < 0: idx = 0 return parts[idx] or remote_addr real_ip = headers.get('x-real-ip') if real_ip: return real_ip.strip() return remote_addr

trusted_hops这个值不是拍脑袋定的，要按你实际的链路层数来：用户 → CDN → 负载均衡 → 应用，那就是 2 或 3，取决于 CDN 会不会改写这个头。最稳的办法是在预发环境把请求头的原始值全打到日志里，自己发几个请求看一眼，比看文档可靠得多。我吃过一次亏，某环境下 CDN 是覆盖写而不是追加，导致跳出层数的假设完全失效，取出来是空的，最后是靠日志定位的。

还有个坑是 IPv6。现在移动网络下很大比例是 IPv6 直连，你的正则如果只匹配 IPv4 格式，取出来就是空的或乱码。IP 解析库如果只支持 IPv4，IPv6 用户的归属地就会全部落到默认值上。上线前一定确认：取 IP 的函数、IP 库、缓存 key 这三处都要能正常处理 IPv6 字符串。另外::ffff:1.2.3.4这种 IPv4 映射格式很常见，入库前建议统一归一化。

3.2 本地库与在线接口怎么选

IP 归属地查询有两种工程方案，各有明确的适用面：

我的判断标准很土：日均查询量过万就走本地库。本地库加载到内存后查询就是一次数据结构查找，几乎不产生可感知的耗时，这对首屏渲染帮助很大。选型时重点看三件事：更新频率（月更够用）、是否支持 IPv6、是否提供 CIDR 段而不是只给单 IP。有些库还提供经纬度近似值，但别太当真，那个经纬度基本是国家或省份中心点，直接拿来在地图上打点会让用户看到所有人都聚在同一个位置。

工程的实现细节上，本地库一定要做单例加载 + 惰性初始化。我见过在每次请求里都重新打开库文件的写法，几十兆的文件读一次几百毫秒，接口直接被打爆。正确做法是应用启动时加载一次，或者用懒加载单例锁住，进程内只保留一份实例。容器环境下注意镜像体积和内存占用，必要时把库文件挂载成卷，别打进镜像。

缓存的粒度也要想清楚。同一个 IP 的归属地在短期内不会变，所以按 IP 做缓存，TTL 给到 7 到 30 天完全合理。但要注意别缓存“内网 IP → 未知”这种结果，因为内网地址在很多环境下会被不同用户复用，缓存了反而会串。另外一个细节：负载高的服务里，热点 IP（比如某运营商的大出口）可能占掉总流量的相当比例，缓存命中率会很高，反而更省。

3.3 归属地解析的精度天花板在哪

这一节是我最想强调的，因为它决定了你做出来的东西能不能用。IP 归属地的本质是“这个 IP 段注册给谁、注册在哪儿”，它跟用户物理位置的关联强度取决于接入方式：

• 家庭宽带：精度最好，通常能到城市甚至区县，因为地址是运营商按区域分配的。但如果用户用的是异地办的宽带或者跨市迁移的账号，就会偏。
• 移动蜂窝网络：精度最差。运营商的核心网出口往往集中在省会或大区，一个出口 IP 后面可能有几十万用户，跨几个地市。这类 IP 查出来的城市经常是省会，跟用户实际所在城市差几百公里。
• 企业专线和数据中心：出口 IP 注册在总部所在地，所有分支机构都走这个出口，查出来全是总部城市。如果用户在用某些企业网络，你怎么查都不准。
• 代理与云主机：基本没有参考价值，甚至可能指向机房所在地。

所以我在任何项目里都会明确一句话：IP 定位只给到城市级，且置信度按“多数情况正确”来设计产品，不按“精确”来设计。产品上要体现为：默认城市可以被用户手动修改，且修改后记住选择；涉及距离、门店、配送范围的判断，一律以用户主动提供或 GPS 结果为准，IP 只用于排序和默认值。

真要做误差量化，可以拿一批已知 GPS 坐标的样本反查 IP 归属地，算算城市命中率和距离偏差的中位数。我在一个区域型项目里做过这个统计，城市级命中率大概是八成出头，剩下的两成里有一半是相邻城市，另一半在省会。这个数据拿来跟业务方沟通特别有效——比空口说“IP 定位不准”有说服力得多。

4. 把两条链路拼成一个能用的定位服务

4.1 服务端接口设计：一次请求返回两层结果

接口设计上我倾向“一次请求拿到所有能立刻拿到的东西”，GPS 结果后续再补。具体就是：前端发起首屏请求时带上业务参数，服务端在同一个响应里返回 IP 解析出的城市、经纬度粗值、ISP、是否移动网络，前端拿到后立刻渲染默认城市；同时前端异步尝试 GPS，成功后单独调一个上报接口把精确坐标和精度带上来，服务端再决定是否更新会话里的位置。

响应体大概长这样：

{ "ipLocation": { "country": "CN", "province": "某省", "city": "某市", "district": null, "lng": 0.0, "lat": 0.0, "accuracyLevel": "city", "isMobile": true, "isProxy": false }, "sessionId": "s_9f2c...", "expireAt": 1710000000 }

这里几个字段是我特意加的，实际用起来很有价值：

• accuracyLevel：明确告诉你这个结果的精度层级（country / province / city / district / coordinate），前端可以据此决定 UI 文案，是“已定位到城市”还是“已获取精确位置”。
• isMobile：是否为移动网络。移动网络的结果我通常会在展示时降一档处理，比如只显示省份不显示城市，避免偏差太大引起困惑。
• isProxy：是否疑似代理或机房 IP。这个在风控里有用，但绝对不能拿来直接拒绝用户，只作为加权因子。误判率不低，直接拦会伤正常用户。
• sessionId：把后续 GPS 上报和这次 IP 解析关联起来，方便算“GPS 结果与 IP 结果的距离差”，这个指标长期看能帮你发现 IP 库的质量变化。

4.2 前端降级流程与状态机

前端的核心不是“怎么拿到定位”，而是“拿不到的时候怎么表现”。我一般用一个四状态的小状态机来管：idle → ip_ready → precise_pending → precise_ready或precise_failed。UI 上永远有东西可显示，不给用户空白页。

具体流程：

1. 页面加载，请求首屏接口，拿到ipLocation，状态进ip_ready，渲染默认城市。
2. 检查权限状态。如果是granted，直接后台静默调getCurrentPosition；如果是prompt，不要自动调，等用户点“使用当前位置”再触发；如果是denied，直接把状态置为precise_failed，不浪费任何一次调用。
3. 拿到精确坐标后，先做坐标转换（如果最终展示用的是 GCJ02 底图），把lng/lat/accuracy/timestamp一起上报。
4. 上报成功后状态进precise_ready，如果 GPS 结果和 IP 结果的城市不一致，以 GPS 为准但要给用户一个确认提示，因为超大偏差往往意味着用户在异地或者 IP 库有问题。

一个容易漏的点：别在页面一加载就弹权限框。用户还没看清这个页面是干什么的，直接弹一个涉及隐私的授权，通过率会明显下降。放在用户产生明确意图的那一刻（点了查附近门店、点了签到），通过率能高不少，而且用户也更清楚这个权限是用来干什么的。这个改动我在两个项目里做过 A/B，通过率提升很明显，成本几乎为零。

4.3 落库、缓存与数据最小化

数据落库这块，一定要克制。精确坐标属于高敏感数据，我的原则是：原始坐标不长期留，只留统计和业务必需的最小字段。

• 精确坐标如果业务需要（比如算配送距离），存但做加密，并且保留时间不超过业务必要周期，比如 30 天。
• 展示和统计用途的坐标，统一降低精度后存储：经纬度各保留 2 到 3 位小数，2 位小数大约是 1 公里量级，3 位是 100 米量级，具体按业务需求选。
• IP 只存脱敏后的值，IPv4 抹掉最后一段，IPv6 抹掉后 80 位。
• 单独的定位原始数据表要有清理任务，别指望它自己变少。

缓存策略上，IP 解析结果按 IP 缓存，会话级的位置按sessionId缓存，精确坐标不进缓存层（避免被日志或监控误采）。这里有个细节：如果用了统一缓存中间件，检查一下它的 key 前缀里有没有带上原始 IP 或坐标，有些默认序列化会把整个请求对象写进 key，那等于把敏感数据写到了缓存集群的元数据里，属于自己给自己挖坑。

5. 常见问题与排查实录

5.1 定位偏差与取 IP 错误的速查表

这张表是我这些年攒下来的，基本覆盖了线上九成以上的投诉场景：

排查的基本顺序我固定为：先确认拿到的原始数据长什么样，再怀疑算法和库。绝大多数问题在第一步就能看出来——是不是私有 IP、是不是坐标系没转、accuracy是不是大得离谱。反过来先怀疑库不准，往往查半天发现是自己取错了字段。

5.2 隐私合规与用户信任的具体做法

这一块不是形式主义，做不好是真会出事的。几条我认为必须落到代码里的：

第一，触发前必须有明确告知。调用定位的那一刻，界面上应该有一句人话，说明要获取位置、用来干什么。别藏在隐私政策里让用户自己找。

第二，提供不亚于授权路径的替代方案。用户拒绝定位之后，页面不能变成不可用状态，必须有手动选择城市或输入地址的入口，而且这个入口要好找，不能藏在角落。这既是体验问题，也是合规要求里“不得因拒绝授权而拒绝提供服务”的落地。

第三，最小必要。业务只需要城市级，就别申请精确坐标。需要在城市级判断的场景里，我甚至会先做粗定位，够了就停，完全不触发精确权限。这个选择让很多项目的授权弹窗数量直接降了一大截。

第四，给用户可见的控制权。提供一个“清除位置记录”的入口，即使只是删掉会话里的缓存，也能显著提升信任感。数据保留的时长写在明面上，别含糊。

注意：日志和监控是最容易泄漏位置数据的地方。上报链路里如果带了完整请求体，坐标和 IP 会原封不动进日志系统。上线前一定检查：日志脱敏规则、错误上报的 payload、以及第三方分析工具的自定义事件字段。

5.3 我在实操里踩过的几个坑

说几个具体的，都是文档里不会写、但实际会浪费你半天时间的。

第一个坑是坐标精度截断的方向。做数据降精度的时候，如果只做四舍五入到 2 位小数，看起来是 1 公里精度了，但实际上在同一个点反复上报，结果会在两个格子之间来回跳，导致“同一用户位置频繁变化”的假象。正确做法是先向下取整到目标精度再存，或者干脆用 geohash 编码存储，后者的好处是前缀可以当索引用，查附近的时候很方便。

第二个坑是 IP 库更新后的缓存不一致。库更新了，但缓存里还是旧结果，导致一部分用户看到的是老城市，另一部分是新城市，看起来像随机 bug。做法是在缓存 key 里带上库的版本号，更新时版本号一变，所有旧 key 自然失效，不用手动清缓存。这个小改动省了很多事。

第三个坑是权限状态判断的时机。页面加载时查一次 Permissions API，之后用户可能在设置里改了权限，但你没重新查，页面还按旧状态走。做法是在visibilitychange事件里重新查一次，页面回到前台时刷新状态，这样用户去设置里开启权限回来后不用刷新页面就能生效。

第四个坑是精度字段的单位。coords.accuracy是米，但有些老设备返回的值明显离谱，比如一万多，那基本是失败降级的结果。我加了个兜底：超过 5000 的直接当作定位失败处理，走 IP 路径，别拿它去算距离，否则会出现用户被判定在几十公里外的荒诞结果。

最后一个，关于测试。浏览器开发者工具里可以模拟地理位置，但那个模拟只改经纬度，不改accuracy，也不模拟权限拒绝之后的降级路径。所以降级路径必须在真机上测：关掉定位服务、拒绝权限、开飞行模式、用内网 IP 访问，这几个场景各走一遍，你会发现一堆平时看不见的问题。我现在的习惯是提测前固定跑一遍这份清单，比上线后救火省心太多。

这套东西做下来，其实没有什么高深的技术，难点全在边界条件的处理和两层结果的拼接逻辑上。把 GPS 当增强项、把 IP 当默认值、把坐标系在展示层解决掉、把取真实 IP 这件事的链路层数搞清楚，剩下的就是耐心把这些分支一个个补全。我个人经验是，定位相关的问题里真正属于“算法不准”的比例很低，绝大部分是取错了数据、没做降级、或者忘了转换坐标系——这些都不需要什么高深方案，需要的只是把每个环节的原始值打出来看一眼。