H5获取GPS坐标实战：坐标系转换与微信定位兼容方案

做 H5 获取手机 GPS 坐标这件事，表面上看就是一行写死的navigator.geolocation.getCurrentPosition()，真正落地才会发现里面全是细节：什么样的浏览器能调通、什么样的场景拿不到权限、安卓和苹果的差异化表现、微信内置浏览器和老版本系统不按套路出牌，还有最容易被忽略的坐标系偏移问题。这篇文章把我做 H5 定位功能时踩过的一些坑和沉淀下来的思路完整梳理一遍，直接给可复用的代码和排查方案，赶时间的人可以按目录跳到对应章节抄作业。

这套内容适合三类人看：第一种是做 Web 端或 H5 页面、需要在网页里获取用户位置的开发者；第二种是做 uniapp 跨端项目、需要把定位能力封装到微信公众平台环境中的人；第三种是接到类似“App 内嵌 H5 页面定位打卡”“户外活动轨迹记录”“配送站点人车绑定”这类需求、前端后端都要动手的全栈同学。基本你看完之后，从接口选型到坐标系换算再到实际部署应该都有谱了。

1. 整体设计与方案选型

1.1 三条技术路径，到底该选哪条

做 H5 获取 GPS 坐标，首先得明确一件事：H5 本身只是一个运行在浏览器里的页面，真正提供定位能力的是浏览器底层的地理定位模块。所以第一层要选的就是 API 方案。我实际接触下来，目前最典型的有三条路。

第一条路是直接用 W3C 标准的 Geolocation API，也就是navigator.geolocation。这是最原生、最不需要依赖第三方的方式，在 PC Chrome、Android 自带浏览器、以及 iOS Safari 上支持度都很好。只要用户允许定位权限，就能拿到经纬度、海拔、速度、精度等信息。适合做纯 H5 网页、不打算引入微信 SDK 的轻量场景。

第二条路是使用微信内置浏览器环境下的 JS-SDK，通过wx.getLocation()来获取定位。这个方案只在微信内有效，本质上是在微信的浏览器外壳里调起系统底层的定位能力，并且需要后端配合签名。为什么会有这条路？因为微信的 X5 内核在部分安卓机上对标准 Geolocation API 的支持并不稳定，时常出现用户点了允许但回调一直不触发的情况。而且微信公众号的定位接口对精准度要求高的场景（比如考勤打卡、配送接单）确实是更可靠的选择。

第三条路是借助 uniapp 这类跨端框架做封装。uniapp 的uni.getLocation()内部会根据平台自动切换实现，你在 H5 平台编译时走的还是浏览器的定位接口，但好处是业务代码统一，后续如果同一个项目要再打包成 App、小程序，不用改业务层。用 uniapp 而不是纯 HTML 写页面，适合团队里已经统一技术栈、不想为 H5 单独维护一套代码的场景。

我个人的建议是，如果你的项目既是公众号 H5 又要求高精度，直接考虑微信 JS-SDK，并在后端把签名流程做扎实；如果只是普通网页工具类应用，标准 Geolocation API 就够用了。如果一开始就觉得未来会往 App 方向扩展，那就用 uniapp 起步，别等到页面写完再迁移，那会是苦差事。

1.2 选型时要提前确认的几个限制条件

除了 API 方案本身，还有一些外部限制条件必须在设计阶段确认清楚，不然等开发到一半再回头看，很可能全部推翻重来。

第一个限制是 HTTPS。浏览器出于隐私保护，明文 HTTP 环境下默认是不予提供地理定位能力的。部分安卓低版本可能还会放行，但 iOS 从 10 之后基本卡得很死。所以你要确认页面域名一定是 HTTPS 的，而且必须是非本地局域网可访问的公网域名。本地调试只能在 localhost 下绕过这个限制，拿到真机上跑联调时，一定要先解决 HTTPS 证书问题。

第二个限制是用户授权体验。浏览器对定位权限的交互策略一直在收紧，Chrome 后来直接要求在navigator.geolocationAPI 被调用时页面必须在“安全上下文”中，而且要求是用户主动触发。所以不要页面一打开就立刻弹授权，最好是在用户点了一个按钮（比如“开始定位”）之后再调接口，这样在 iOS 端的授权弹窗成功率会高很多。

第三个限制是坐标系的终点。这个问题特别容易被新手忽略——GPS 标准坐标系是 WGS-84，但国内地图 SDK 使用的大多是 GCJ-02（高德、腾讯）或 BD-09（百度），国内外开发者在使用原生定位拿到的坐标直接打到国内地图上时，会看到明显偏移几百米的情况。这也是为什么必须要把“坐标转换”列入核心方案里，我会在第五部分专门展开讲。

选型这件事不是简单地比较哪个 API 好用，而是要结合你的业务终点来倒推。先把上面的 HTTPS、授权交互、坐标系这三点定了，后续开发才不会返工。

2. 核心细节解析：坐标系、精度与误差

2.1 WGS-84、GCJ-02、BD-09 到底差在哪

最近我刷到不少人在问“为什么外卖员利用火星坐标也能精准定位”，其实这正好点出了国内地图定位的关键概念：你们看到的坐标有两种，一种是 GPS 设备接收卫星信号直接算出的 WGS-84 经纬度，另一种是国内地图应用上显示“火星坐标”。这里的“火星坐标”就是 GCJ-02，在国家标准要求下，所有在中国境内发布的合法地图公开接口都必须对真实坐标进行一次非线性偏移加密，偏移量通常在几十米到几百米，不同区域偏移量不一样，同一个点的偏移方向也各不相同。

打个比方，WGS-84 坐标就像是地球表面的真实地址，而 GCJ-02 相当于每个地方都有一个“代号地址”，你在国内地图 App 上看到的永远是这个“代号地址”。所以当你用navigator.geolocation.getCurrentPosition拿到的是前者，直接拿去高德地图上做标记或算距离，偏个三五百米完全不奇怪。

百度坐标系 BD-09 更特殊，它是在 GCJ-02 基础上又叠加了一次自己的加密偏移，只有在百度系产品内部使用。因此接入百度地图时，不能直接用 GPS 坐标，也不能用高德坐标，必须先把 WGS-84 转成 GCJ-02，再转成 BD-09，或者直接调百度地图提供的坐标转换 API。

这也是为什么大家会看到我前面列出的热搜词里同时出现了“python 将gps经纬度转换为高德经纬度”、“坐标转换”、“gis坐标成面”这类词——本质上大家遇到的问题是同一个：拿到 GPS 坐标后，往地图上展示时要进行坐标系换算。

2.2 影响定位精度的几大因素

用 H5 获取 GPS 坐标，精度并不是恒定的，而是受多个因素共同影响。首先是卫星信号遮挡，在室内、地下车库、高楼密集的“城市峡谷”区域，可见卫星数量骤降，定位误差会明显拉大；其次是多径效应，手机接收到的卫星反射信号和直达信号叠加，距离计算会出现偏差，在玻璃幕墙密集的商业区尤其明显；第三是设备硬件和系统策略，不同手机的 GPS 芯片定位能力差别悬殊，某些安卓机为了省电会长期使用基站辅助定位而不是真正等 GPS 卫星锁星，这会让精度直接掉到几十米甚至上百米量级。

另外，浏览器的地理位置接口通常是由操作系统底层提供的，它内部也有自己的定位策略。比如 Chrome 在部分安卓机上会优先使用网络定位（WiFi 扫描和基站），而不是等待 GPS 冷启动获取更精确的卫星定位。所以表格里enableHighAccuracy: true非常重要，它是在向浏览器申请更高精度的定位模式，但不保证一定生效；在 iOS 上，Safari 的 Geolocation 实现相对靠谱，会尝试升级为 GPS 定位。

所以你看，做 GPS 坐标获取不能只写一个读取函数，还要在界面上把“定位中”“精度不足”“授权失败”这几种状态都给用户区分清楚，否则用户看到坐标，但其实这个坐标可能偏了几百米，就会误以为是你的程序写错了。

2.3 坐标系转换计算：从 GPS 到高德/腾讯

既然高频遇到“GPS 经度纬度转高德经度纬度”的需求，这里就把核心思路和公式讲明白。

WGS-84 转 GCJ-02 时，通常把一个经纬度点先减去一个固定基准点（例如(纬度 35.0, 经度 105.0)），然后用一个公开的绕地球旋转参数计算偏移量。网上流传很多版本的转换代码，原理都是类似的。我自己用下来，下面这段 JavaScript 代码是相对靠谱的：

// WGS-84 转 GCJ-02 var PI = 3.1415926535897932384626; var A = 6378245.0; var EE = 0.00669342162296594323; function transformLat(x, y) { var 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) { var 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) { var dLat = transformLat(lng - 105.0, lat - 35.0); var dLon = transformLon(lng - 105.0, lat - 35.0); var radLat = lat / 180.0 * PI; var magic = Math.sin(radLat); magic = 1 - EE * magic * magic; var 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: lng + dLon, lat: lat + dLat }; }

这套代码是把 WGS-84 坐标纠偏到 GCJ-02。为什么外卖员用火星坐标也能精准定位？因为他们用的配送 App 显示的就是火星坐标，骑手所在的位置和目的地在同一个坐标系里，地图渲染、路径规划、距离计算都基于这个偏移后的坐标，偏移量在同一个城市内是连续且一致的，所以从用户体验看完全不偏，只有把 GPS 坐标直接和地图坐标混着用时才会出问题。

如果需要反过来把高德坐标还原成原始 GPS 轨迹，也存在 GCJ-02 转 WGS-84 的公开算法，但要注意这种转换是近似操作，精度会损耗，并不是完美反解，只能恢复到一个近似真实坐标。这也就是为什么有“gps数据导出地图”这个需求时，你一定要确认导出数据的坐标系标注，不然导出的轨迹和你的原始 GPS 记录根本不是同一种坐标。

3. 实操过程：一步一步实现 H5 GPS 坐标获取

3.1 纯 H5 Geolocation API 的最小实现

先放一个最基础、可以直接运行的 HTML 页面，这个页面会动态展示当前的经纬度和精度信息：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>H5 GPS 定位示例</title> </head> <body> <h3>当前定位</h3> <p id="status">正在请求定位权限...</p> <button id="startBtn">开始定位</button> <button id="stopBtn">停止定位</button> <script> const statusEl = document.getElementById('status'); let watchId = null; function onSuccess(pos) { const coords = pos.coords; const accuracy = coords.accuracy; statusEl.innerHTML = ` 纬度: ${coords.latitude.toFixed(6)}<br> 经度: ${coords.longitude.toFixed(6)}<br> 精度: ${accuracy.toFixed(1)} 米<br> 海拔: ${coords.altitude ? coords.altitude.toFixed(1) + 'm' : '无'}<br> 速度: ${coords.speed ? coords.speed.toFixed(2) + ' m/s' : '无'}<br> 时间戳: ${new Date(pos.timestamp).toLocaleTimeString()} `; // 业务代码：这里可以做坐标转换并发送到后端 // const gcj = wgs84togcj02(coords.longitude, coords.latitude); // console.log('高德坐标', gcj); } function onError(err) { switch (err.code) { case err.PERMISSION_DENIED: statusEl.textContent = '用户拒绝定位授权'; break; case err.POSITION_UNAVAILABLE: statusEl.textContent = '当前无法获取定位'; break; case err.TIMEOUT: statusEl.textContent = '定位超时'; break; default: statusEl.textContent = '定位失败: ' + err.message; } } document.getElementById('startBtn').addEventListener('click', () => { if (!navigator.geolocation) { statusEl.textContent = '此浏览器不支持 Geolocation'; return; } // 单次获取 navigator.geolocation.getCurrentPosition(onSuccess, onError, { enableHighAccuracy: true, timeout: 10000, maximumAge: 0 }); // 如果需要持续跟踪位置，用 watchPosition // watchId = navigator.geolocation.watchPosition(onSuccess, onError, { // enableHighAccuracy: true, // timeout: 10000, // maximumAge: 1000 // }); }); document.getElementById('stopBtn').addEventListener('click', () => { if (watchId !== null) { navigator.geolocation.clearWatch(watchId); statusEl.textContent = '已停止追踪'; } }); </script> </body> </html>

这段代码把定位的几个核心点都覆盖了：enableHighAccuracy希望尽量使用高精度模式；timeout: 10000表示 10 秒内没有拿到定位就触发错误回调；maximumAge: 0表示不接受缓存位置，每次都重新获取。需要持续位置更新时，用watchPosition替代getCurrentPosition，返回一个 watchId，用clearWatch停止。

3.2 真机调试的三种方式

现在很多人在 H5 调试时只用 Chrome DevTools 的模拟定位，这存在一个巨大缺陷：模拟器里给的是一个固定假坐标，根本验证不了真实设备的 GPS 表现。所以我把实际验证时会用的三种方式列出来，建议至少测两种。

第一种是 Chrome DevTools 传感器面板。在开发者工具里按Ctrl+Shift+P（Mac 上是Cmd+Shift+P），输入 Sensors，打开传感器标签，可以手动设置经纬度坐标模拟指定位置。优点是快速验证页面在不同坐标下的渲染效果，缺点是模拟不出真实设备的授权弹窗和精度波动。

第二种是安卓手机连 USB 调试，用 Chrome 远程调试。手机开启开发者模式后，把网页在手机浏览器里打开，然后电脑 Chrome 访问chrome://inspect，就能看到手机当前网页的实时 console 和 Network。你可以在手机里走动，观察定位值是否变化，也可以看到是否触发了权限弹窗。

第三种是直接用微信开发者工具查验公众号 H5 定位。如果你的页面最终运行在微信里，那就用微信开发者工具，在“菜单 -> 工具 -> 真机调试”里选择二维码扫码，然后在手机上真实打开页面并操作。这种方式会真实调用手机的定位服务，连微信 JS-SDK 的签名问题都能一起验证。

这里要特别提醒：在室外测试时，冷启动 GPS 需要时间。手机刚从飞行模式切换过来，或刚开完飞行模式回到正常状态，首次锁定卫星可能需要几十秒，如果你的timeout设得太短，比如只给了 3 秒，那定位基本不会成功。实际项目中我推荐设置至少 10 秒到 15 秒，并配合一个“正在定位”的 loading 状态，让用户感知到系统在等 GPS 卫星。

3.3 精度校准与数据上报

拿到经纬度后，通常不直接上报，而是要结合coords.accuracy做一次质量判断。我之前做过一个移动巡检项目，要求定位精度必须小于 20 米，否则不算有效打卡。于是我在代码里加了一个阈值判断：

function onSuccess(pos) { const { latitude, longitude, accuracy } = pos.coords; if (accuracy > 20) { statusEl.textContent = `当前精度 ${accuracy.toFixed(1)} 米，请移动到更开阔处`; // 继续请求或等待下一次定位 if (watchId === null) { watchId = navigator.geolocation.watchPosition(onSuccess, onError, opts); } return; } // 达到精度要求再上报 sendLocationToServer(lng, lat, accuracy); }

这样做的好处很明显：不让质量差的数据污染业务数据库。你可以把精度阈值做成可配置参数，比如考勤严格一点用 20 米，普通展示用 100 米。而在上报数据时，最好把坐标原始系和目标坐标系一起带上，比如coordinateSystem: 'wgs84'或者coordinateSystem: 'gcj02'，这样后端在汇总、导出、画轨迹时能明确知道每个点用的什么坐标。

4. 微信内嵌页面与 uniapp 环境实战

4.1 微信内置浏览器为什么不能依赖标准 API

我在做公众号 H5 定位时遇到一个比较典型的现象：Android 端同一个页面，用 Chrome 打开定位正常，但用微信自带的浏览器打开，navigator.geolocation.getCurrentPosition虽然会弹出权限询问，但点了允许后回调却一直不触发，偶尔还直接进入POSITION_UNAVAILABLE错误分支。

这种情况并不是代码写错了，而是微信内置浏览器内核与系统底层位置服务之间的兼容性问题。尤其在某些使用了 X5 内核的安卓机上，Geolocation API 的 promise 回调根本不会有效抛出。所以在公众号类的 H5 页面里，更稳妥的方案是使用微信官方 JS-SDK 里的wx.getLocation()。这个接口由微信原生实现，它直接调起微信 App 的定位服务，返回经纬度、速度和精度。使用前提是必须先在公众号后台绑定 JS 接口安全域名，并且后端使用appid、secret、timestamp、nonceStr等参数生成签名。

4.2 引入微信 JS-SDK 的完整步骤

第一步，在页面中引入微信 JS-SDK 文件。推荐用官方提供的 npm 包，如果你用的是普通 H5 页面，直接加 script 标签也可以：

<script src="https://res.wx.qq.com/open/js/jweixin-1.6.0.js"></script>

第二步，后端通过接口返回签名配置。这个签名生成规则要特别注意，签名用的 URL 是当前页面的完整 URL（包括#之后的 hash 部分），不同页面要单独请求签名。我这里给一个前端的调用示例：

axios.post('/api/wx/sign', { url: window.location.href.split('#')[0] }) .then(res => { wx.config({ debug: false, // 上线前改成 false appId: res.data.appId, timestamp: res.data.timestamp, nonceStr: res.data.nonceStr, signature: res.data.signature, jsApiList: ['getLocation'] }); });

第三步，在wx.ready回调里调用定位接口：

wx.ready(function () { wx.getLocation({ type: 'gcj02', // 微信默认返回 gcj02 坐标 success: function (res) { console.log('纬度:', res.latitude, '经度:', res.longitude, '精度:', res.accuracy); // res.speed 速度，res.altitude 海拔 }, fail: function (err) { console.error('定位失败', err.errMsg); } }); });

这里有个关键点：微信getLocation接口返回的坐标类型默认是gcj02，如果你业务后端要存的是 WGS-84 原始 GPS 坐标，是需要做反向转换的。注意微信 SDK 签名机制一直在迭代，比如后来版本对 URL 的判断更严格，建议签名请求和wx.config都放在同一个页面生命周期里，避免 hash 变化导致签名失效。

4.3 uniapp 开发 H5 并嵌入微信公众号的定位写法

如果你在用 uniapp 做公众号 H5，uni.getLocation会封装跨平台的差异。我直接在 uniapp 里这样写：

uni.getLocation({ type: 'gcj02', altitude: false, success: (res) => { console.log('经度', res.longitude, '纬度', res.latitude); }, fail: (err) => { console.error('定位失败', err); } });

uniapp 在H5平台编译时，默认语法上会基于 HTML5 Geolocation 来实现getLocation。但前面也说了，微信内置浏览器的标准 API 不太稳，所以我在项目中通常会做一个运行时检测：如果检测到当前是在微信浏览器（navigator.userAgent中包含MicroMessenger），就改走微信 JS-SDK 的wx.getLocation，否则走 uniapp 自带的uni.getLocation。

这里分享一个我从实战中总结出的消息桥接体验：如果你在 uniapp 项目中既有 H5 页面又有 App 端页面，而 H5 页面需要和 App 容器通信，最规范的方式是通过 Webview 桥接，H5 页面postMessage给 App，App 收到后再调用原生定位，把坐标返回到 H5 页面。这种场景下不要直接在 H5 里调uni.getLocation，因为在 App 的 Webview 环境里uni.getLocation不一定会被正确注入，而且这种调用方式也无法和你的 App 原生定位统一逻辑。

4.4 App 内嵌 H5 页面如何同步定位与缓存

经常有人问“App 内嵌 H5 页面怎么清除缓存”或者“h5 跳转 app 怎么做”。在做定位功能时，App 内嵌 H5 的关键问题其实不是缓存，而是通信和权限。H5 页面在 App 的 Webview 里请求定位时，浏览器内核依然需要系统授权，而原生 App 可以先请求一次定位权限，然后把定位结果通过 JSBridge 传给 H5 页面，这样体验最顺畅。

至于缓存问题，公众号 H5 的缓存会直接影响 JS 脚本更新，新增定位逻辑后用户手机上可能还在跑旧版本，导致wx.getLocation一直报config:fail。遇到这种情况，排查建议是先让用户清除微信缓存或者用浏览器无痕模式测试。我在项目里也会给静态资源 URL 加版本参数，比如app.js?v=20250117，强制触发缓存刷新，这样定位代码更新后能更快生效。

5. 坐标转换与地图数据融合

5.1 WGS-84 转高德坐标的两种方式

第一种是前端本地算法转换，也就是我在第二部分写的那段 JavaScript 函数。它的优势是零网络请求，速度快，不依赖外部服务，适合单个点位展示。劣势是它是一个公开近似算法，和官方 SDK 的转换结果对比会有零点几米的差异，但对绝大多数 LBS 业务来说完全可以接受。

第二种是调用高德或腾讯地图的坐标转换 API。高德提供https://restapi.amap.com/v3/assistant/coordinate/convert接口，腾讯也有类似的坐标转换接口。好处是官方算法，转换结果准确稳定，而且支持批量转换（一次最多几十个点）。劣势是依赖网络，且这些 API 通常要求你有个人或企业开发者 key，调用量过大会产生费用。

实际项目里我倾向于混合使用：前后端传输和存储用 WGS-84 原始 GPS 坐标，展示到地图上之前用本地函数转成 GCJ-02，如果要做轨迹纠偏或边界判断，再调高德 Web 服务 API，因为这类 API 还顺带提供逆地理编码、行政区划判断等辅助能力。

5.2 GPS 数据导出地图，怎么保证不漂移

很多业务场景需要把采集到的一批 GPS 点导成 KML 或 GeoJSON，再导入 GIS 系统或者 Google Earth 里查看。这时候最常见的坑是坐标系搞混：你的采集设备存的是 WGS-84，但地图平台默认期望的是 GCJ-02，直接导进去之后所有点都偏离出街区。

我的建议是导出时一定加上坐标系统字段，或者做一次预处理后再导出。比如要导到 Google Earth（使用 WGS-84），那就直接用原始 GPS 坐标生成 KML；如果要导到国内地图 Web 平台做可视化，就要先转成 GCJ-02 再导出 GeoJSON。你可以用 Python 脚本批量处理，我经常用的是下面这个思路：

import json import math def wgs84_to_gcj02(lng, lat): # 省略重复代码，和前面的 JS 逻辑一样 pass # 读取原始 GPS 点 with open('gps_points.json', 'r', encoding='utf-8') as f: points = json.load(f) # 转换为高德坐标并输出 for point in points: point['lng'], point['lat'] = wgs84_to_gcj02(point['lng'], point['lat']) point['coordinateSystem'] = 'gcj02'

这里“坐标转换”不只是简单换几个常数，而是整体几何语义的变化。你可以在转换后用高德地图 JS API 标点核对，如果所有点都落在真实道路可见位置，那基本就是准的。

5.3 从 GPS 数据到“成面”和“坐标拾取”

除了点展示，实际项目中还经常需要把 GPS 轨迹组成多边形（比如绘制巡检区域、电子围栏）。这里会用到“gis坐标成面”的能力。如果是 Web 端，可以用高德地图 JS API 的AMap.Polygon把转换后的边界点连接成面；如果是后端计算面积，可以在转成 GCJ-02 后调用高德行政区查询接口，或者用 Python 的shapely库直接在本地处理 GeoJSON 数据。

另外“天地图坐标拾取”也是常用工具，天地图有官方的坐标拾取页面，你点一下地图上的任意位置就能显示该点的经纬度。拿这种工具来校准 GPS 和 GCJ-02 的差异很直观，因为拾取的通常是国内火星坐标，而你设备上拿到的原始 GPS 坐标在地图上会偏移，找个地标建筑分别取两组坐标，就能算出自己区域的近似偏差量。

6. 常见问题与排查技巧实录

6.1 定位一直失败或者超时

这种情况占了我平时答疑的一半以上，原因绝大多数是以下几种：

• HTTPS 没有配置好，页面还是 HTTP 访问，iOS 直接拒绝。
• 用户在浏览器设置里关掉了定位权限，或者曾经选了“一次允许”后又手动关闭。
• timeout设置太短，GPS 冷启动未完成就被判定失败。
• 在室内或者信号很差的环境测试，周围卫星被阻挡。
• 安卓手机上开启了省电模式，系统强制停用了 GPS 精确定位。

实际排查时，第一件事是打开 Chrome DevTools 的 Console，看有没有安全上下文相关的报错；然后到手机系统的设置-应用管理-对应浏览器，检查定位权限是不是“允许”；再换到室外空旷环境测试。如果本地定位没问题但用户报告有问题，请让用户打开一个能正常定位的网页（比如高德 H5 页面）对比测试，如果网页版地图能定位但那你的页面不行，问题就不在系统定位服务，而在你的代码或配置上。

6.2 微信定位报 config:fail / 签名错误

“签名错误”是公众号 H5 最常见的痛点。我通常会按照这几个步骤排查：

1. 确认公众号后台已配置 JS 接口安全域名，并且和当前页面域名完全一致（包括端口号也不能漏）。
2. 确认后端生成签名时使用的 URL 和前端页面当前 URL 是否完全一致，通常取window.location.href时要去掉#后面的部分。
3. 确认appid是否正确，公众号的 appid 和小程序的 appid 不能混用。
4. 确认系统时间和服务器时间相差不超过 5 分钟，签名机制对时间戳很敏感。

签名问题还有个隐蔽点：如果你在wx.config之前用了window.location.href，但后续页面发生路由跳转，hash 变化时签名可能就失效了。所以我会在页面加载入口固定取一次 URL，后续不要再动态修改wx.config的签名值。如果是 uniapp 的 H5 页面，路由是在 history 或 hash 之间切换，签名也要基于最终加载完成的地址来生成，这一点最好是前后端联调时明确好。

6.3 拿到的坐标在地图上偏移几百米

这就是坐标系统混用造成的。我不止一次遇到这种情况：页面用navigator.geolocation获取坐标，展示在高德地图上偏了几百米，开发者还以为是自己代码写得有问题，浪费了半天的排查时间。其实只是少了坐标系转换这一步。

如果你已经明确要给高德或腾讯地图用，尽量在拿到 GPS 原始坐标后立刻转成 GCJ-02，并且后续所有逻辑都用转换后的坐标，不要混着用。如果你想保留原始 GPS 轨迹，那就在数据库里把两套坐标都存下来，字段名写清楚lat_wgs84、lng_wgs84、lat_gcj02、lng_gcj02。

很多做外卖、配送物流、共享出行的人，最终直接使用高德 SDK 的话，其实完全不用自己存储 WGS-84，因为高德 SDK 的 Web 端定位服务本身是会返回 GCJ-02 坐标的。但如果你的项目还要和物联网硬件设备对接，设备上报的协议里通常都是 WGS-84，这时候你就必须有个统一的坐标系转换中间层。

6.4 常见问题速查表

6.5 一个最容易忽视的细节：海拔与速度

很多人拿 GPS 坐标只是为了经纬度，但coords.altitude和coords.speed对一些户外应用非常重要。比如高程剖面分析、骑行速度记录，就是靠这两个字段。需要注意的是，H5 Geolocation 返回的altitude在部分设备和浏览器上可能是 null，不要直接把 null 传给地图 SDK，否则会报错。处理时要做空值判断，或者用altitude: 0兜底。

速度字段也很有意义，比如判断用户是否在移动，可以用来做自动定位频率调整：速度高时提高watchPosition的更新频率，静止时可以降低更新频率，节省电量。我做过一个巡检项目，就是靠这个逻辑在后台记录用户的移动轨迹，既控制了 GPS 耗电，又保证了路径完整度。

我个人在实际操作中的一个深刻体会是：做 H5 定位，最怕的不是代码写不出来，而是你永远不知道用户的设备、浏览器、网络环境是什么组合。所以在上线前，务必把精度过滤、超时重试、授权失败引导这三件事做到位。比如定位失败时，页面不要直接显示“获取失败”就完了，应该给用户两个操作：一个是“重新定位”，另一个是“手动输入当前位置”。这样即使 GPS 彻底不可用，业务也能继续推进，大量户外采集场景都依赖这样的降级策略。

最后再分享一个小技巧：在 H5 页面里获取坐标后，建议顺手把定位结果缓存到sessionStorage里。这样用户在一次会话内重复打开页面时，可以直接先展示上一次的定位结果，再在后台异步更新。用户点击“定位”按钮后，能明显感觉到秒开反馈，而不是每次都等一个漫长的定位转圈。当然，缓存时间不能太长，一般 5 分钟到 10 分钟就足够了，否则你展示的可能是用户早就不在的位置。