起因：一次看似普通的投诉，把系统问题全部炸出来了

那天客服收到一个反馈：

“骑手明明已经到门口 8 分钟了，系统还显示在 2 公里外。”

我们第一反应是：

• GPS漂移？
• WebSocket延迟？
• 前端渲染问题？

但进一步排查之后发现一个更严重的问题：

不是某一层错了，而是整条链路没有“统一语义”

---

1. 事故复盘：系统看起来正常，但数据已经失真

当时的链路是这样的：

Android采集GPS
  ↓
Node.js转发
  ↓
直接入库
  ↓
前端展示

表面问题：

• 数据正常写入
• WebSocket正常推送
• 前端没有报错

但真实问题是：

❗同一个“位置”，在系统里有三种语义

来源	坐标系	含义
GPS	WGS84	原始值
高德SDK	GCJ02	偏移值
历史数据	BD09	百度体系

结果就是：

👉 系统内部根本不存在“统一的位置”概念

---

2. 第一个爆点：轨迹“瞬移”，其实是坐标系战争

最严重的问题不是漂移，而是：

轨迹被“错误解读”了

典型现象：

骑手在A楼下
→ 下一秒出现在B小区
→ 再跳回A

最初怀疑：

• GPS抖动
• 手机省电策略
• 定位SDK问题

但最终定位到根因：

WGS84 / GCJ02 / BD09 混入同一条轨迹链路

---

3. 当时最致命的设计缺陷：数据库没有“语义字段”

原始表结构：

lat
lng
created_at

这个设计的问题是：

你存的不是“位置”，而是“数值”

缺失三个关键语义：

• 坐标系
• 采集方式
• 数据可信度

4. 第二个爆点：GPS不是失效，是“被误判”

很多人以为问题是：

GPS 在室内不准

但实际是：

系统逻辑是“二选一”

GPS成功 → 用GPS
GPS失败 → 不上报

这导致一个隐性问题：

系统没有“降级路径”

真实世界是连续状态：

• GPS弱
• WiFi可用
• 基站可用
• 三者混合

但系统设计是离散判断。

---

5. 我们做的第一刀：引入“定位可信度模型”

我们不再接受“一个坐标”，而是：

{
  "lat": 31.23,
  "lng": 121.47,
  "source": "GPS/WIFI/CELL",
  "accuracy": 12.3,
  "confidence": 0.87
}

---

Android侧策略改成：

if (gps.accuracy < 30) {
    return gps
}

if (wifiAvailable) {
    return fusedLocation
}

return lastKnownGoodLocation

核心变化：

从“是否成功” → 变成“哪个更可信”

---

6. 第二刀：统一坐标系（这是最关键的一次决策）

当时有两个方案：

方案A：各端自己处理坐标系

• 灵活
• 但会失控

方案B：服务端统一转换（我们选的）

最终策略：

所有输入 → GCJ02统一入库

原因很直接：

“多坐标系共存 = 长期技术债爆炸”

---

数据库新增字段：

coord_system TINYINT NOT NULL

并强制校验：

if (coordSystem == null) {
    throw new IllegalStateException("coord_system required");
}

---

7. 第三刀：逆地理编码从“读路径”挪到“写路径”

这是另一个隐性成本炸点。

原逻辑：

用户请求位置
→ 计算逆地址
→ 返回

问题：

• 同一坐标被重复解析
• QPS上来后直接打爆第三方API

重构后：

写入时：
    坐标 → 逆解析 → 存地址

读取时：
    直接返回

这一步的本质变化是：

把计算从“请求时”迁移到“数据生成时”

8. 最终架构（重构后的能力层）

多源定位输入
    ↓
定位融合层（可信度模型）
    ↓
坐标统一服务（GCJ02）
    ↓
轨迹标准化存储
    ↓
逆地理编码（写路径）
    ↓
实时推送服务
    ↓
前端展示

---

9. 重构后最明显的三个变化

1）轨迹“跳点”消失

不是优化算法，是统一语义之后自然消失。

---

2）定位问题从“Bug”变成“数据质量问题”

以前：

“为什么位置错了？”

现在：

“这个点可信度是多少？”

---

3）成本下降（尤其是逆解析）

• 请求量下降 60%~90%
• 缓存命中率显著提升

---

10. 一个关键认知（比实现更重要）

这次重构之后我们得出的结论是：

位置系统的本质不是“定位”，而是“统一空间数据语义”

---

如果不做统一，会发生什么？

• 每个端都在“修数据”
• 每个模块都在“猜坐标系”
• 每个问题都变成“偶现Bug”

---

如果统一之后：

• 数据变稳定
• 问题变可解释
• 系统变可演进

---

11. 总结（工程结论）

一个稳定的位置系统必须满足三点：

① 统一坐标系

避免空间语义污染

② 引入可信度模型

避免二值判断（成功/失败）

③ 计算前移（写路径）

避免读路径复杂计算

本次案例定位采用迈云LTS提供统一位置服务能力