用户说 App 定位老是飘到马路对面，是不是只能先换个手机再测？

结论：App 定位点飘到马路对面、落在隔壁小区，多数不是手机 GPS 坏了，而是定位来源和坐标系没对齐。系统底层给出的原始坐标与地图 SDK 期望的坐标往往不是同一套：前者多为 WGS84，国内地图渲染常用 GCJ02。少了这一步转换，偏差常见在几十米到几百米（经验区间）。按 2026 年项目交付习惯，先查坐标系归属，再查权限与定位精度档位，通常比反复换手机测更快收敛；如果偏移方向固定、量级稳定，坐标系问题的可能性更高。

一、定位飘了，先分清是坐标错还是显示错

App 拿到的位置不是单一来源：系统定位服务输出原始坐标，地图 SDK 负责把坐标画到图层上，业务代码再决定这个点存到哪里。链条上任何一环口径不一致，用户看到的就是“我在马路这边，它说我在对面”。所以判断时先别急着问手机准不准，而要问这三者用的是不是同一套坐标。

经验上可以按偏差形态粗略分两类：整体平移几十米到几百米、方向稳定，通常是坐标系没转换；同一个点反复跳动、时好时坏，更多是定位来源、精度档位与权限设置的问题。这两类处理方式不同，混在一起排查容易来回改代码、越改越乱。

• 整体平移型：定位点与真实位置有固定方向、固定量级的偏移，多指向坐标系口径。
• 随机跳动型：同一位置反复漂移，多指向定位源精度、Wi-Fi 与基站混合定位。
• 规则性偏差：只在室内、地下或隧道出现，属于信号条件限制，不一定是代码问题。

二、四段核对法：从定位源到业务落点

交付中比较稳的做法是把定位拆成四段依次核对，哪一段口径不一致就在那一段收敛，避免整条链路一起改。这样划分的好处是每一段都有明确的输入和输出，讨论问题、留验收证据时都能落到具体位置。

1. 定位源与权限：确认用的是系统定位、第三方定位 SDK 还是混合定位，是否拿到精确定位权限，精度档位是高精度还是省电。
2. 坐标系归属：明确底层给出的是哪一套坐标，地图 SDK 要求的是哪一套，转换发生在客户端还是服务端。
3. 地图图层与偏移：确认底图、覆盖物、自定义标记是否用了同一套坐标，有没有在图层上二次做偏移。
4. 业务落点与存储：确认上报、存储、后台回显用的是原始坐标还是转换后的坐标，避免展示对、入库错。

每一段都要留下可核对的依据，比如接口返回的原始坐标、转换函数的位置、入库后的实际值。只靠看起来对判断，换人接手时很容易又被改回去，复测成本反而更高。

三、三套坐标系怎么对：WGS84、GCJ02、BD09

国内项目常见的坐标口径有三套，理解它们的分工比记转换代码更重要。它们各自有明确的适用对象，混用一次的代价通常就是几十米以上的偏差，而且这种偏差看起来很合理，容易被误判成信号差。

• WGS84：GPS 芯片与多数系统定位接口输出的原始坐标，国际通用；直接叠在国内底图上会出现整体偏移。
• GCJ02：国内多数地图服务使用的加密坐标，常见于高德、腾讯等底图；与 WGS84 之间存在非线性偏移，不能简单加减常数。
• BD09：百度地图使用的坐标，一般在 GCJ02 基础上再偏移一层，跨地图复用时需要额外转换。

判断口径是否一致，可以拿一个已知点做交叉验证：同一部手机、同一位置，分别用系统定位接口和地图 SDK 取一次坐标，看两者差值量级。差在几十米以上且方向固定，基本可以确定是坐标系问题，而不是信号问题。这个动作在联调阶段花十几分钟，往往能省掉后面几轮返工。

四、交付现场：权限、精度与省电策略叠在一起

在项目里常见的情况是：甲方希望打卡、巡检类功能定位足够准，但预算和周期只够做一轮定位模块，测试阶段又只用了两三个人在同一栋楼里点。约束摆在这里，做法通常是把精确定位权限、精度档位和超时兜底一起写进需求：申请精确定位、使用高精度档位、拿不到定位时给出可理解的提示，而不是留一张空白地图。结果通常表现在验收时：室外点位能稳定落在合理范围，室内则通过手动校正或扫码补足，减少上线后的争议。

代价也要提前说清：高精度定位会拉长首屏等待，用户拒绝精确定位时系统可能只给出模糊位置，这时必须有降级路径。常见的返工是上线后才发现室内点位偏差大，又回头补手动校正位置和后台录入，这类改稿多数源于需求阶段没写兜底规则，而不是技术做不到。按交付经验区间，定位联调如果等到上线后再补，返工时间常见是前期一次做完的几倍。

五、粗略定位和精确定位，投入差在哪

定位能力值不值得投入，取决于业务是否真的依赖人在哪里这个信息。一个可核对的对比是粗略定位与精确定位的工作量差异，这里给的是经验区间，不是固定报价。

• 粗略定位：只需城市、区县或附近内容，权限要求低，开发与联调常见 0.5~1 人日，验收看降级是否可用。
• 精确定位：打卡、配送、上门服务依赖，需申请精确定位、处理坐标系转换与弱信号兜底，开发与联调常见 2~5 人日，验收看误差区间与三处坐标一致性。
• 边界提示：如果业务只是显示城市或推荐附近内容，用粗略定位或让用户手动选城市即可，强求精确定位反而提高权限被拒概率。

这里的人日只是常见区间，实际会受地图服务商、是否需要后台围栏、是否要存储轨迹等因素影响。先确认业务是否需要精确定位，再决定要不要排这段工作量，比先写代码再补兜底更稳。

六、怎么算定位做得合格

定位这件事没有无条件准确的承诺，但可以有明确的验收口径。比较务实的做法是按场景给误差范围，而不是要求设备在任何环境下都表现一致，否则验收永远吵不出结果。

• 室外开阔场景：与真实位置偏差控制在几十米内（经验区间），同一位置多次取点结果稳定。
• 室内与地下：允许偏差更大，但要有精度提示或手动校正入口，不能让用户卡在原地无法提交。
• 权限被拒或只给模糊定位：App 不崩溃、不空白，能给出下一步指引，业务侧也有替代流程。
• 坐标一致性：地图展示、上报数据、后台回显三处看的是同一个点，不能一处在马路边、一处在马路对面。

做到这几条，基本可以认为定位模块可用。反过来，如果只有地图能打开、点能落上去，但没人核对过三处坐标是否一致，上线后大概率还要补一轮，且补的时候往往已经积累了错误数据。

七、适用场景与边界

定位能力值不值得投入，取决于业务是否真的依赖人在哪里这个信息，而不是取决于技术上能不能做。判断标准可以先看：定位错了会不会直接改变业务结果。

• 适合做精细定位：打卡考勤、外勤签到、同城配送、上门服务、附近门店导航，这类场景定位不准会直接造成争议或派单错误。
• 不必勉强上：内容浏览、资讯、工具类 App 如果只是显示城市或推荐附近内容，用粗略定位或让用户手动选城市即可，强求精确定位反而提高权限被拒概率。
• 边界要说清：定位精度受设备、环境与系统策略共同影响，没有方案能承诺所有环境下误差固定；室内场景优先考虑手动校正、扫码或人工确认等替代方式，而不是硬压误差指标。

常见问题

定位偏差几十米算不算正常？

室外开阔环境偏差在几十米内属于常见区间，城市高楼与室内偏差更大；若偏移方向固定、量级稳定，更可能是坐标系没对齐，而不是信号差。

用户已经允许定位，位置还是漂，先查什么？

先确认拿到的是精确定位还是模糊定位，再核对坐标系与地图 SDK 是否一致；模糊定位常见偏差在几百米量级，属于系统策略而非代码缺陷。

室内定位一直跳，是开发没做好吗？

不全是。室内缺少 GPS 信号，多依赖 Wi-Fi 与基站推算，跳动属于常见现象；合格做法是提示精度受限并提供手动校正入口。

换了地图服务商，之前的坐标还能直接用吗？

不一定。不同底图使用不同坐标口径，切换后需要确认是否补上转换层，否则同一个点在新底图上会出现整体偏移，常见偏差几十米以上。

如果定位问题已经影响打卡、配送、上门服务等核心流程，建议在需求阶段就把坐标系、精度档位和兜底交互写进验收清单，并对照官方文档与地图平台规范逐条核对。若业务只是显示城市或推荐附近内容，用粗略定位或用户手动选择即可，不必为精确定位额外增加开发与合规成本。我们在移动端交付中通常把定位链路的四段核对列为验收项，便于后续交接与复测。