在公众号网页里获取用户地理位置，调试时最容易被忽略的不是权限配置，而是坐标系。前端拿到 latitude 和 longitude 后，如果直接塞给地图组件，标注点可能跑到隔壁楼或者对面车道。这个偏差通常不是定位芯片精度不够，而是坐标基准没有对齐。微信 JS-SDK 的 getLocation 接口允许输出 WGS84 和 GCJ-02 两种坐标，一旦获取端与展示端使用不同基准，结果就会偏移数百米。理解这一点，比反复调整地图中心点更有效。
一、微信返回的经纬度可能是哪种坐标
国际上最常提到的是 WGS84，它由 GPS 接收机直接输出，Google 地图、OpenStreetMap 等海外服务通常使用这一基准。GCJ-02 是国测局对 WGS84 做了非线性加偏后的坐标，也叫火星坐标。高德地图、腾讯地图以及微信内置地图在展示位置时，都基于 GCJ-02。百度的 BD-09 则在 GCJ-02 基础上又做了一次偏移。
微信 JSSDK 的 getLocation 提供了 type 参数，官方文档给出的可选值是 wgs84 和 gcj02。虽然默认值写的是 wgs84，但在实际项目中，不同微信客户端版本对默认类型的处理并非绝对统一。尤其当页面同时在 iOS 和 Android 上运行时，如果不显式传 type，可能会看到同一份代码在 iPhone 上基本准确，在安卓机上却系统性偏移。因此只要你的地图组件属于国内厂商，就应该在调用时显式指定 type 为 gcj02。
wx.getLocation({
type: 'gcj02',
success: function (res) {
var latitude = res.latitude;
var longitude = res.longitude;
console.log(latitude, longitude);
},
fail: function (err) {
console.error(err);
}
});
这里 res.latitude 和 res.longitude 都是数字，但 openLocation 和部分地图组件对类型要求严格，必要时可以使用 Number 显式转换。带上 type 参数，等于从源头确定了坐标基准，后续地图展示就不用再做猜测。
二、地图组件和 openLocation 需要什么坐标系
高德地图 JS API、腾讯位置服务、微信 openLocation 接口都要求 GCJ-02 坐标。高德地图如果传入 WGS84，标注会向东南方向偏移一段距离；如果传入 BD-09，则会偏移到另一个位置。百度地图 JavaScript API 则需要 BD-09，直接给 GCJ-02 仍然会偏。
微信的 openLocation 用于调起内置地图查看位置，它不接受百度坐标，也不建议传 WGS84。正确做法是把 getLocation 获取的 gcj02 经纬度原样传入。示例如下：
wx.openLocation({
latitude: Number(latitude),
longitude: Number(longitude),
name: '当前位置',
address: '用户授权的位置',
scale: 15
});
如果后端存的是 WGS84，前端调高德地图之前要转换。可以引入 gcoord 这类坐标转换库，而不是在前端写固定偏移。GCJ-02 不是简单线性偏移，手工加减几行代码只能在小范围内勉强可用，城市级应用会出现明显误差。下面是一个 Node 端转换示例：
const gcoord = require('gcoord');
const wgs84Point = [116.404, 39.915];
const gcj02Point = gcoord.transform(
wgs84Point,
gcoord.WGS84,
gcoord.GCJ02
);
console.log(gcj02Point);
原则上建议坐标转换放在后端统一处理。前端只负责展示，不维护转换算法，这样更换地图厂商时接口层可以保持不变。若前端需要快速验证，也可以在浏览器环境使用对应的转换库，但不要在生产环境直接暴露转换密钥或依赖不稳定算法。
三、完整的公众号页内地图展示流程
公众号网页要获取位置并在地图上标记，至少需要完成三步：注入 JSSDK 权限签名、调用 getLocation 获取坐标、初始化地图组件并用 marker 展示。签名由后端根据当前 URL 生成，前端引入 jweixin 脚本后使用 wx.config 注入。下面给出一个以高德地图为例的完整前端示例，其中后端签名部分用注释略过。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>公众号位置展示</title>
<style>
#map { width: 100%; height: 400px; }
</style>
</head>
<body>
<div id="map"></div>
<script src="https://webapi.amap.com/maps?v=2.0&key=你的Key&plugin=AMap.Marker"></script>
<script src="https://res.wx.qq.com/open/js/jweixin-1.6.0.js"></script>
<script>
wx.config({...}); // 后端注入签名
wx.ready(function () {
wx.getLocation({
type: 'gcj02',
success: function (res) {
var map = new AMap.Map('map', {
zoom: 15,
center: [res.longitude, res.latitude]
});
new AMap.Marker({
position: [res.longitude, res.latitude],
map: map
});
}
});
});
</script>
</body>
</html>
这段代码中 wx.config 的签名参数来自后端接口，jssdk 权限列表需要包含 getLocation 和 openLocation。高德地图的 center 参数接受经度在前、纬度在后，与微信返回顺序正好对应。只要 getLocation 显式返回 gcj02，高德地图就能在正确位置显示用户标记。实际项目中建议同时处理 getLocation 的 fail 回调，提示用户重新授权或引导开启定位。
如果在高德地图上仍发现少量偏移，先不要怀疑坐标系，可以先核对传入的经纬度顺序是否为 [longitude, latitude]，以及 res.longitude 与 res.latitude 是否被字符串拼接后传给地图。高德地图允许字符串坐标，但最好用 parseFloat 或 Number 转换后再传入，避免一些低版本浏览器出现精度下降。
四、后端存储与转换时要注意的几个点
当系统需要保存用户位置时，应先定义统一坐标系字段。建议数据库中所有经纬度一律保存 GCJ-02，或者保存 WGS84 并同时记录 coordinate_system 字段。不要一部分记录存 WGS84，一部分存 GCJ-02，否则后续做距离计算、轨迹回放或区域统计时会非常被动。
如果业务上需要同时支持百度地图和海外地图，可以保存 WGS84 作为原始值，因为从 WGS84 转换到 GCJ-02、BD-09 都有成熟算法，而反过来从 GCJ-02 转 WGS84 通常会产生细小误差。用户授权后马上拿到 WGS84，服务端可以在入库前转成 GCJ-02，再返回给前端展示。示例如下：
const express = require('express');
const gcoord = require('gcoord');
const app = express();
app.use(express.json());
app.post('/transform', (req, res) => {
const { latitude, longitude } = req.body;
const result = gcoord.transform(
[Number(longitude), Number(latitude)],
gcoord.WGS84,
gcoord.GCJ02
);
res.json({ latitude: result[1], longitude: result[0] });
});
app.listen(3000);
最后，微信 openLocation 只接受 GCJ-02 坐标，如果拿 WGS84 去调起，用户看到的定位点会偏移严重。对于公众号开发来说，调 getLocation 时显式指定 type 为 gcj02，地图组件选择高德或腾讯，数据库和接口统一 GCJ-02，就能规避大多数坐标系带来的偏移问题。遇到地图显示异常，先排查坐标系链路，往往比反复调整代码更快定位原因。