企业官网建设流程全解析

上周有个做活动页的同行来问我，说他在页面上同时接了浏览器定位和一个 IP 归属地查询，结果两边给出的位置差了四十多公里——GPS 说用户在城南的园区，IP 库说用户在隔壁城市。他一度怀疑是定位代码写错了，折腾了一下午才发现，这俩东西压根就不是一回事。精准 GPS 定位靠的是设备里的卫星与基站混合解算，IP 地址获取拿的是网络出口的身份标识，一个精确到米级、一个只能到城市级，把它们放在同一套逻辑里比较，本身就是设计上的错位。

这篇东西想聊的就是这件事：在一个链接或页面里，怎么把 GPS 定位和 IP 地址这两条链路都打通、参数怎么调、坐标系怎么对、失败之后怎么兜底、哪些环节最容易翻车。适合已经能跑通基础 demo、但在真实流量里被各种异常打得满头包的前端和后端同学看，也适合刚接触位置服务、想先搞清楚全局再动手的人。我下面讲的顺序，基本就是我当年从“能跑”到“敢上线”踩过来的顺序。

1. 先分清两条链路的物理来源，别拿米级精度去校准城市级数据

1.1 卫星、基站与出口地址：三种完全不同的定位依据

浏览器里的navigator.geolocation背后并不是单一手段，它是一套混合解算：优先读取设备 GNSS 芯片的卫星解算结果，信号弱的时候退到 Wi-Fi 热点指纹和蜂窝基站三角定位。所以你在户外空旷地打开定位，往往两三秒就返回一个精度半径十米以内的点；钻进地下车库，返回的可能是精度半径两千米的一个大圆圈。这个“精度半径”字段非常关键，它告诉你这个点有多可信，很多人拿到坐标就直接用，从来不读accuracy，这是第一个坑。

IP 定位的原理完全不同。服务端从一次 HTTP 请求里拿到来源地址，然后去查一张预先构建好的地址段与地理区域的映射表。这张表是运营商分配地址段时登记的信息，粒度天然就粗，通常是城市级，部分地址段能细到区县，还有一部分只能定位到省份甚至只标“保留地址”。它的准确率高度依赖地址库的新鲜度，移动网络的出口地址共用严重，一个城市级出口后面可能挂着几十万用户。

所以正确的预期是：GPS 用来回答“这个人在哪条街”，IP 用来回答“这个人大概在哪个城市”，两者的用途不能互换。

1.2 为什么两者会“打架”，以及该怎么取舍

回到开头那位同行的问题。他看到的矛盾其实很正常：用户在园区里连着公司 Wi-Fi，出口地址走的是总部机房，而总部机房登记在隔壁城市，GPS 显示的是真实位置。这种情况下该信谁？取决于你的业务要干什么。

如果是做“附近的门店推荐”“周边服务匹配”，必须用 GPS，因为精度要求摆在那儿，IP 只能用来做初始化的粗筛。如果是做“内容语言/区域版本切换”“风控的地域异常判断”，IP 反而更合适，因为它不依赖用户授权、不触发弹窗、不打断流程，覆盖率接近百分之百。

我一般的做法是两条链路都拿，但明确主次：GPS 为主，IP 为辅。页面加载时先用 IP 把大区域定下来，渲染一个粗粒度的默认内容；用户授权后再用 GPS 精修，把结果覆盖上去。这样用户即使拒绝授权，页面也不会空着。这个降级顺序后面第 5 章会展开讲。

2. 浏览器定位 API 的真实边界：参数、超时与权限的三重博弈

2.1 getCurrentPosition 的三个参数，多数人只用了第一个

navigator.geolocation.getCurrentPosition(success, error, options)的第三个参数才是决定体验的地方，但大量代码里写着{}或者干脆省略。三个可调项里，enableHighAccuracy决定是否强制走高精度通道（GNSS 优先），timeout决定你最多愿意等多久，maximumAge决定可以接受多久以内的缓存结果。

function locate() { return new Promise((resolve, reject) => { if (!navigator.geolocation) { reject(new Error('GEO_UNSUPPORTED')); return; } navigator.geolocation.getCurrentPosition( (pos) => { resolve({ lat: pos.coords.latitude, lng: pos.coords.longitude, accuracy: pos.coords.accuracy, timestamp: pos.timestamp }); }, (err) => reject(err), { enableHighAccuracy: true, timeout: 8000, maximumAge: 60000 } ); }); }

这几个值怎么定，我踩过的经验是这样的：enableHighAccuracy: true在移动端会明显增加首次定位时间，冷启动时可能要等五六秒，某些机型上还会触发额外的系统级提示。如果只是要判断“用户在哪座城市”，把它设成false反而更快，Wi-Fi 定位足够。如果业务确实需要街道级精度，那就开着，但timeout一定要给到 8 秒以上，给 3 秒基本等于自杀，因为冷启动根本来不及。

maximumAge是个容易被忽视的省时开关。设成60000，意味着浏览器可以返回一分钟内的缓存位置，省掉一次重新解算。对于“打开页面看附近门店”这类场景，一分钟前的坐标完全够用；但如果是导航或者打卡，就必须设成 0，宁可多等几秒也要拿实时值。

2.2 权限弹窗不出现、定位永远超时：两个最典型的“玄学故障”

第一个故障：代码写了，浏览器就是不弹权限框，error回调也不触发，或者直接返回PERMISSION_DENIED。九成的情况是页面不在安全上下文里。定位 API 只在 HTTPS 或者 localhost 下可用，用内网 IP 访问、用 file 协议直接打开 HTML，都会静默失败。我见过有人在测试环境用http://192.168.x.x调试了一下午，最后发现是协议问题。

排查这个问题的顺序建议是：先看协议，再看域名是否在浏览器黑名单里，最后看用户是否之前点过“阻止”并且浏览器记住了这个选择。第三步最阴险——权限状态是持久化的，用户一次误点拒绝，之后这个域名下再也不会弹窗，error.code会直接给 1。解决办法是引导用户去地址栏左侧的站点设置里手动恢复，代码层面你能做的只有把PERMISSION_DENIED和其他错误区分开，给出不同的文案。

const ERR_MSG = { 1: '定位权限被拒绝，请在浏览器站点设置中重新允许', 2: '当前无法获取位置信号，请到开阔处重试', 3: '定位超时，请检查网络或稍后重试' }; function handleGeoError(err) { const tip = ERR_MSG[err.code] || '定位失败'; // 关键：区分拒绝与超时，前者重试无用，后者可以重试 return { code: err.code, retryable: err.code !== 1, tip }; }

第二个故障：POSITION_UNAVAILABLE（错误码 2）。这个在桌面端特别常见，很多台式机没有 Wi-Fi 模块、没有 GNSS，只能靠 IP 反查，浏览器拿不到可用的信号源，就一直超时。所以桌面端不要指望 GPS，直接走 IP 降级是更务实的选择。

2.3 watchPosition 的适用场景与被滥用的代价

watchPosition是持续监听位置变化，回调会随设备移动不断触发。它适合导航、轨迹记录、跑步计步这类需要连续位置的场景，不适合“打开页面读一次位置”的需求。我见过有人图省事，直接用它替代getCurrentPosition，结果页面上挂着一个永不关闭的监听器，用户切到后台还在耗电，内存也一直涨。

如果确实要用，务必保留返回的 watchId 并在组件卸载或页面隐藏时清除：

let watchId = null; function startWatch(onUpdate) { watchId = navigator.geolocation.watchPosition(onUpdate, () => {}, { enableHighAccuracy: true, maximumAge: 0, timeout: 15000 }); } function stopWatch() { if (watchId !== null) { navigator.geolocation.clearWatch(watchId); watchId = null; } } document.addEventListener('visibilitychange', () => { if (document.hidden) stopWatch(); });

还有一个细节：watchPosition的回调频率不是固定的，设备静止时可能很久不触发，移动时可能一秒好几次。不要假设回调间隔，也不要每次都往服务端打点，客户端先做距离过滤（比如移动超过 20 米才上报），能省掉大量无意义的请求。

3. 坐标系：那个能让坐标平白偏移几百米的关键环节

3.1 三套坐标系并存，直接混用必然错位

拿到经纬度之后，很多人以为任务结束了，直接丢给地图组件渲染，然后在某些地图上看到标记稳稳落在马路对面的河里。这不是定位不准，是坐标系没对上。

国内常见的有三套：WGS84 是设备原始输出的国际通用坐标；GCJ02 是在 WGS84 基础上做了非线性偏移的加密坐标，国内主流地图组件普遍使用它；BD09 又是在 GCJ02 基础上再做一次偏移。三套之间转换有公开算法，但都是有损的，来回转两次误差会累积。

浏览器getCurrentPosition返回的是 WGS84。如果你把它直接喂给使用 GCJ02 的地图，偏移量在城市里通常是几百米级别，在郊区可能更大。这个偏移没有规律，不是一个固定的加减常数，所以只能靠转换函数处理。

const PI = Math.PI; const A = 6378245.0; const EE = 0.00669342162296594323; function outOfChina(lng, lat) { return lng < 72.004 || lng > 137.8347 || lat < 0.8293 || lat > 55.8271; } 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 transformLng(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) { if (outOfChina(lng, lat)) return [lng, lat]; let dLat = transformLat(lng - 105.0, lat - 35.0); let dLng = transformLng(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); dLng = (dLng * 180.0) / (A / sqrtMagic * Math.cos(radLat) * PI); return [lng + dLng, lat + dLat]; }

这段代码网上一搜一大把，但真正容易出问题的是转换时机。我的建议是：数据从设备出来那一刻就明确标记坐标系来源，一路带着这个标记走，在渲染前的一步统一转换，绝不在中间层反复转。

3.2 怎么验证转换结果是对的

转换做对了没有，肉眼是看不出来的。实操中我用两个办法验证。一是选一个已知精确位置的地标，在地图上打点，看落点是否在建筑物的正确位置，偏移超过 50 米就是转换没做或者做反了。二是取一个点做往返转换，WGS84 → GCJ02 → WGS84，往返误差应该在米级以内，如果往返之后差了上百米，说明中间某一步用错了公式方向。

注意：GCJ02 转 WGS84 的“逆运算”并不能用简单的取反实现，常见做法是用迭代逼近，或者在 WGS84 转 GCJ02 的基础上反解。直接用正变换的差值去减，误差会积累到十几米甚至更多。

另外提醒一点，做数据存储时，数据库里统一存 WGS84 是更稳妥的选择，因为它是无偏移的原始值，未来换地图服务商也不用重新刷库。只在渲染层做转换，这个原则能帮你省掉很多麻烦。

4. 服务端取 IP：从请求头里挖真实地址的正确姿势

4.1 代理头字段的优先级与伪造风险

客户端是拿不到自己真实公网 IP 的，必须由服务端从请求里读。而在今天的部署形态下，请求要经过 CDN、负载均衡、反向代理好几层，req.socket.remoteAddress拿到的往往是中间层的地址，不是用户地址。于是就得读转发头。

常见的几个头字段：X-Forwarded-For是逗号分隔的链路列表，最左边是客户端、最右边是最后一跳代理；X-Real-IP通常只有一个值，由代理写入；CF-Connecting-IP、True-Client-IP这类是特定 CDN 厂商的自定义头。关键认知是：这些头都是请求头，客户端可以伪造。如果你的服务直接暴露在公网、前面没有可信代理，直接信任X-Forwarded-For最左值就是给攻击者开门。

正确的读取逻辑应该是：先判断请求是否来自你信任的代理层（通过比对来源地址是否在已知代理网段内），只有在确认来自可信代理时才采信转发头，否则一律用remoteAddress。

const net = require('net'); function isPrivate(ip) { if (!net.isIPv4(ip)) return false; const p = ip.split('.').map(Number); return p[0] === 10 || (p[0] === 172 && p[1] >= 16 && p[1] <= 31) || (p[0] === 192 && p[1] === 168) || p[0] === 127 || (p[0] === 169 && p[1] === 254); } function normalize(ip) { if (!ip) return ''; // 处理 IPv4 映射的 IPv6 形式，例如 ::ffff:1.2.3.4 if (ip.startsWith('::ffff:')) return ip.slice(7); return ip.trim(); } function getClientIp(req, trustedProxies = []) { const remote = normalize(req.socket.remoteAddress); const trusted = trustedProxies.includes(remote) || isPrivate(remote); if (trusted) { const xff = req.headers['x-forwarded-for']; if (typeof xff === 'string' && xff.length > 0) { // 从左往右找第一个非内网地址，跳过伪造的内网段 const list = xff.split(',').map(s => normalize(s)); const firstPublic = list.find(ip => net.isIP(ip) && !isPrivate(ip)); if (firstPublic) return firstPublic; } const real = normalize(req.headers['x-real-ip']); if (real && net.isIP(real)) return real; } return remote; }

4.2 内网地址、IPv6 与本地开发的干扰

调试阶段最容易碰到的现象是：本地跑起来，拿到的 IP 是127.0.0.1或者::1，然后拿去查归属地，接口返回一堆空值或者“本机地址”。这不是接口坏了，是你压根没走公网。本地开发时这一点基本无解，只能接受——要么用固定的测试 IP 做 mock，要么对接一个明确标注“内网地址直接返回空”的分支。

IPv6 的普及带来了另一个麻烦。很多 IP 地理库对 IPv6 的支持远不如 IPv4，同样一段地址，IPv4 能给到城市，IPv6 只能给到国家甚至直接查不到。所以如果业务强依赖归属地，一个可行的降级策略是：IPv6 查询失败时，尝试从请求的其他线索推断，比如Accept-Language和时区，虽然粗糙，但比完全空着好。

还有一个实践中的坑：X-Forwarded-For的解析必须严格校验每一段是不是合法 IP。有次线上日志里出现了带字母的字符串，追下去发现是某个中间层把请求头和端口拼一起写进去了。不校验直接拿去查库，轻则查不到，重则被注入奇怪的内容。

5. IP 定位的粒度预期与 GPS 失败后的降级编排

5.1 IP 库能给出什么，不能给出什么

IP 归属地查询返回的典型字段包括国家、省份、城市、运营商、经纬度。这里的经纬度要特别警惕：它不是用户的位置，而是这个地址段登记地或者运营商机房所在地的坐标。你在城市中心打一个点，然后加个半径圆圈，看起来挺像那么回事，但它和真实位置的偏差可能在几十公里。所以千万别把 IP 返回的经纬度当成精确位置展示给用户，说什么“你在 XX 路附近”，那是会出事的。

正确的用法是把它当成一个筛选项：用省份或城市字段做内容分发、做区域白名单、做数据统计的粗分类。真要展示位置，用城市名字符串，不要用坐标。

5.2 一套能上线的降级编排

我在真实项目里用的编排是这样的，四步，每一步都有明确的超时和失败出口：

第一步，页面初始化，服务端在渲染时就把 IP 归属地算好塞进首屏数据，不额外发请求。这一步几乎不会失败，最差情况是返回空，那就用一个默认区域。

第二步，页面挂载后判断权限状态。如果navigator.permissions.query({name: 'geolocation'})返回granted，直接调定位，不用等用户点击；返回prompt，不要自动调——自动调会立刻弹窗，很多用户还没搞清楚要干什么就被打断，体验很差，通常的做法是先展示一个“获取附近内容”的按钮，用户点了再调。

第三步，定位调用带上 8 秒超时。成功就校验精度半径accuracy，如果大于 1000 米，说明是基站或 Wi-Fi 粗定位，可以用于城市级场景，但不要用于街道级展示；如果小于 100 米，视为高可信，直接采用。

第四步，定位失败，回落到第一步的 IP 结果，同时在 UI 上做轻提示，比如“已按所在城市为你推荐”，让用户知道这不是精确位置，避免误解。

async function resolveLocation() { const ipFallback = await fetch('/api/ip-region').then(r => r.json()); const perm = await navigator.permissions .query({ name: 'geolocation' }) .catch(() => ({ state: 'prompt' })); if (perm.state === 'denied') { return { source: 'ip', ...ipFallback, precise: false }; } try { const pos = await locate(); // 内部含 8 秒超时 const precise = pos.accuracy <= 100; return { source: 'gps', ...pos, precise }; } catch (e) { return { source: 'ip', ...ipFallback, precise: false, reason: e.code }; } }

这套编排的价值在于：任何一条链路挂掉，页面都还有东西可展示，而且展示的内容和它的可信度是匹配的。做位置相关的功能，最难的不是拿到数据，而是让用户对数据的精度有正确预期。

6. 授权链路与数据处理：把“能拿到”和“该不该拿”分开

6.1 权限申请的时机，比权限本身更影响转化

技术上能调起定位弹窗，不代表应该在页面加载的零点几秒内就调。浏览器弹窗是一次强打断，用户必须在“允许”和“阻止”之间做选择，而此时他还不知道你要位置干什么。真实数据上，加载即弹窗的通过率明显低于“先说明用途再弹窗”的做法。

我的做法是在按钮旁边写清楚一句话：“用于为你推荐 3 公里内的服务点，位置仅用于本次查询，不会保存”。然后按钮点击时才触发权限申请。这句话不是走形式，它同时解决了合规要求和转化率问题。另外要提供手动输入城市或区域的入口，让拒绝授权的用户也能走通流程，而不是被一堵墙挡住。

还有个小细节：如果用户之前拒绝过，再次调用 API 不会弹窗，直接返回错误码 1。这时候不要反复调，那只会让用户困惑。正确的处理是显示引导文案，告诉他去哪里手动开启，并同时启用 IP 降级，保证功能不中断。

6.2 坐标数据的存储边界与脱敏

原始经纬度属于敏感信息，能不存就不存。如果业务确实需要记录，比如做配送范围校验，我的处理方式有这么几条：

• 精确坐标只在当前会话内使用，服务端做完距离计算就丢弃，不落库。
• 需要落库的场景，把坐标降精度，保留到小数点后两位（约 1 公里粒度），足够做统计，不足以还原到具体楼栋。
• IP 地址同样处理，存储时做掩码，IPv4 保留前三段，IPv6 保留前 64 位。
• 日志里不打印完整坐标和完整 IP，这一条最容易被忽略，出事往往出在日志。

function maskIp(ip) { if (net.isIPv4(ip)) { const p = ip.split('.'); return `${p[0]}.${p[1]}.${p[2]}.*`; } if (net.isIPv6(ip)) { return ip.split(':').slice(0, 4).join(':') + '::/64'; } return ''; } function roundCoord(v, digits = 2) { return Number(v.toFixed(digits)); }

提示：掩码和降精度要在数据进入存储层之前完成，一旦原始值写进了表或者日志，后续再清洗的成本会高得多，而且很容易漏。

6.3 一个常被忽略的复核点：时区与语言也是位置线索

最后补充一个实用技巧。当 GPS 被拒绝、IP 库又只能给到省份时，客户端和服务端其实还有别的线索可以交叉验证：Intl.DateTimeFormat().resolvedOptions().timeZone能给出设备时区，Accept-Language能给出语言偏好。这两者组合起来，往往能把“大概率在哪个区域”缩得更准，用来做降级时的默认区域选择很够用。

不过要清楚它们的定位是“校验”而不是“主数据”。时区可以被用户手动改，语言偏好和实际位置也没必然关系。我一般在拿到 IP 省份后，用这两个值做一次合理性检查：如果 IP 说用户在北方某省，时区却是另一个时区的偏移，那这条 IP 结果的可信度就要打折扣，可能需要走更保守的默认策略。这种交叉校验不增加任何用户打扰，成本极低，但在脏数据多的场景下能挡掉不少误判。

踩过几次坑之后我最大的体会是，定位这件事的难度从来不在 API 调用本身——两行代码就能拿到坐标。难的是把精度预期、失败降级、坐标系转换、隐私边界这几件事摆在同一张图上考虑清楚，让每一条数据从产生到消费都带着明确的上下文。这套思路理顺了，换成任何一家地图服务、任何一门后端语言，迁移成本都很低。