小程序按距离排门店，用户站在店门口却显示好几公里，是定位飘了还是距离没算对？

门店距离算得离谱，先分清是定位飘了还是坐标系没统一

结论先行：小程序里按距离排门店，用户站在店门口却显示好几公里，多数不是手机 GPS 失灵，而是坐标系没统一或距离口径不一致。手机系统定位的原始值更接近 WGS84，国内地图服务和小程序地图组件多按 GCJ02 处理，两者直接混算，偏移常见在几十米到几百米；门店间隔本来就只有几百米时，排序很容易翻车。按 2026 年项目交付习惯，先把「定位来源—坐标转换—距离计算—前端展示」四步对齐同一坐标系和同一单位，再去真机核对，通常比反复换定位接口更有效。

这类反馈常出现在上线之后：用户在楼下点开小程序，最近的店排在第三位，第一位却是两公里外的另一家。开发在开发者工具里试又正常，因为模拟坐标恰好和测试数据同源。要快速定性，把定位返回的经纬度、后端存的经纬度、前端参与计算的经纬度分别打印出来，看哪一段发生了变化。

• 定位层：授权方式、是否开启高精度，影响坐标本身误差有多大。
• 坐标系层：WGS84、GCJ02、BD09 混用，表现为整体平移，而不是随机跳动。
• 计算层：距离公式、单位、精度截断、缓存时机，影响排序稳不稳。

同一个门店，为什么两套代码能算出两个距离

距离不难算，难的是前后端对「用哪套坐标、算哪种距离、留几位小数」没有约定。常见三类坑：定位坐标没转换就直接代入公式；前端用直线距离、后端用路径距离，两种结果混在同一个列表里排序；把距离四舍五入到公里再排序，几百米的差别被抹平。

2026 年比较省事的做法，是在接口文档里把口径写死：存储统一 GCJ02，距离单位用米，排序在前端完成，展示时再按需转成「约 300 米」「1.2 公里」。口径写清楚之后，测试用例也能照着写，不容易出现开发说对、运营说错的情况。

三种距离计算方式，成本和效果差在哪

下面这组对比按项目交付经验整理，都是经验区间，会随服务商配额、门店数量和调用频率变化，只作取舍参考。

• 只算直线距离：本地计算，几乎不产生调用成本，单次耗时常见在毫秒级；缺点是与实际步行路径有出入，遇到河、高架、封闭园区会明显不符。
• 走路径规划接口：更贴近真实到店路径，单次耗时常见在几百毫秒量级，多按调用量计费或有免费配额上限，门店多、刷新频繁时要提前算配额。
• 预计算并缓存距离：门店位置固定时提前算好，运行时只查表，响应快、省调用；代价是门店增减或搬迁要重建缓存，缓存过期会让用户看到旧距离。

取舍逻辑大体是：用户只想看附近有哪些店，直线距离通常够用；要回答走过去多久、怎么走，就需要路径能力；门店名单稳定且访问量大，预计算更划算。三者也不互斥，常见组合是列表页用直线距离排序，详情页再给步行时间。

一套可落地的排查顺序：从坐标到排序

排序问题不适合一上来就改公式，按顺序排查能少走弯路，适合到店自提、上门派单、周边推荐这类场景。

1. 确认定位来源：系统定位、小程序定位组件、用户手动选点，三种来源的坐标基准可能不同。
2. 打印三段坐标：定位返回值、入库值、参与计算值各打印一次，先看有没有整体平移。
3. 核对坐标系标注：数据库字段、接口文档、缓存里是否写明坐标系，没写明的一律先按可疑处理。
4. 统一计算口径：前后端约定同一种公式和单位，排序只在同一口径下做，避免两种距离混排。
5. 真机核对排序：iOS 与 Android 各一台，在店门口、隔一条街、室内各看一次排序是否合理。

三层要解决的问题不同：定位层解决准不准，坐标层解决偏不偏，计算层解决稳不稳。跳过坐标系核对直接调排序权重，很容易把坐标问题当成算法问题。

哪些场景值得做精，哪些场景不必过度投入

值得投入的：到店自提、上门派单、周边推荐、巡检打卡、配送范围判断。这些场景用户能直接感知距离，偏几百米就会影响选择，适合把坐标系与计算口径一次性定清楚。

不必过度投入的也要说清楚：只展示城市级分布、按行政区归类，或者门店之间本来就隔几公里，几十米偏移不影响决策，不必为坐标转换做大量精调。室内、地下车库、大型商场内部定位信号本身弱，靠坐标转换解决不了，更实际的做法是让用户手动选点、扫门店码或输入地址，再按区域粗略排序。边界可以记成：室外比距离先统一坐标系，室内比距离先换定位方式。

交付现场的一次排查：门店排序偏差怎么收敛

有一次交付的约束很典型：小程序已经上线，预算有限，没有专职后端，门店六七十家，用户反馈最近的店不在第一位。我们没有直接改排序算法，而是先加了一个内部用的坐标对照页，把定位原始坐标、转换后坐标、门店坐标和算出的距离并排显示。半天内就定位到根因：门店坐标入库前转过一次，定位拿到的坐标又转了一次，等于转了两次，部分门店整体偏移，排序随之错乱。

做法分三步：先按统一口径清洗入库数据并标明坐标系，再把距离计算收敛到一处，最后加一个自查入口，运营可随时抽查某家门店的距离是否合理。结果是指标回到可解释范围，室外定位偏差回落到常见经验区间内（大致十几米到几十米，随机型、天气和建筑遮挡变化），相关反馈明显减少。代价也真实：数据清洗加联调大约占了两到三天工期，还要多跑一轮真机验证和一次版本发布，但比上线后被反复投诉再回头改数据划算。

验收建议按可核对口径来，而不是看着差不多：

• 同一地点连续取 3 到 5 次定位，排序稳定，不出现来回跳位。
• iOS 与 Android 真机各至少一台，店内、店门口、隔街各测一次。
• 数据库与接口文档标明坐标系，距离单位统一，只在展示层做换算。
• 用户拒绝定位时，有手动选城市、手动搜索门店的兜底路径。

反例也要知道：只在一台开发机上验证排序、只在模拟坐标下测试、门店坐标来源不明就直接参与计算，都属于高风险。做到坐标可追溯、距离口径唯一、真机有记录，排序问题才不容易反复。

常见问题

门店距离算不准，是不是手机定位本身不行？

多数不是。手机定位有几十米误差，但排序差出几公里，通常出在坐标系混用或距离口径不一致，先核对数值再考虑换设备。

算距离该用直线距离，还是步行距离？

看用途。只要看附近有哪些店，直线距离够用且成本低；要给出步行时间或导航引导，就得走路径规划，耗时和费用都更高。

为什么后端算的距离和地图上量的不一样？

常见是两边坐标系不同，或一边按米、一边按度取精度。把存储和计算统一到 GCJ02 并对齐单位，差异通常就回到可解释范围。

门店数量不多，能不能不调接口，直接写死距离？

门店位置固定时可以预计算并缓存，省掉频繁调用；但门店会增减、用户位置在变，缓存要设好更新时机，别让它长期过期。

海外门店能用同一套距离算法吗？

不一定。国内常用 GCJ02，海外多用 WGS84，混在一份数据里排序会出错。跨境业务建议按区域分组计算，或统一存原始坐标再各自转换。

行动指引：如果小程序已经上线、用户反馈最近的店不对，先按「定位来源→三段坐标→坐标系标注→计算口径→真机排序」顺序排查，别急着重写排序逻辑。适用边界：室外到店、派单、附近推荐值得投入坐标校准；纯展示、室内场景优先换方案。按 2026 年项目交付习惯，把坐标系和距离口径写进接口文档与验收清单，能省下大部分返工。