直接用Workerman发送原始经纬度会导致前端轨迹卡顿，根本原因在于服务端未做消息聚合与插值，导致高频碎点冲击地图SDK渲染节奏；正确做法是在Worker进程内缓存骑手短时位置、按200ms节奏线性插值生成平滑路径段再推送，前端交由地图动画API（如AMap.MoveAnimation）驱动，避免逐点setPosition引发重绘排队和跳变。
为什么直接用 Workerman 发送经纬度会导致轨迹卡顿？
Workerman 本身是 PHP 的异步 I/O 框架，不处理前端渲染逻辑，但很多人误以为“后端推得快，前端就一定滑得顺”——实际卡顿往往出在 WebSocket 消息频率与前端 requestAnimationFrame 节奏不匹配，或服务端未做消息合并/降频。骑手位置每秒上报 1–3 次很常见，但地图 SDK（如高德、百度、Mapbox）对连续 marker.setPosition() 调用非常敏感：频繁调用会触发重绘排队、坐标插值被跳过，最终表现为“瞬移”或“阶梯式移动”。
关键点不是 Workerman 推得慢，而是推得“太碎”或“太直”。必须在服务端做两件事：聚合短时位移 + 插值补点，再发给前端。
如何在 Workerman 中实现位置插值并控制推送节奏？
不要每次收到 GPS 原始点就立刻 $connection->send()。应在 Worker 进程内为每个骑手维护一个缓存结构，例如：
$riders[$rider_id] = [
'last_point' => ['lng' => 116.48, 'lat' => 39.99, 'ts' => 1717023456],
'pending_points' => [], // 存最近 2–3 秒的原始点
'next_send_time' => 0, // 下次可推送时间戳（毫秒级）
];
当新位置到达时：
- 追加进
pending_points，并更新last_point - 若距离上次推送已超
200ms，且至少有 2 个点，则用线性插值生成 5–8 个中间点（用lng1 + (lng2-lng1)*t公式），再清空pending_points - 设置
next_send_time = microtime(true) * 1000 + 200，避免高频刷屏
这样前端每 200ms 收到一组平滑路径段，而非单点，地图 SDK 可自然做匀速过渡动画。
前端接收后怎么让 marker 动起来不跳？
别用 marker.setPosition() 逐点设——这是最大误区。正确做法是把服务端发来的插值点数组交给地图 SDK 的轨迹动画 API：
- 高德地图：用
AMap.MoveAnimation或AMap.Polyline+setPath()配合showOnMap() - 百度地图：调用
marker.setAnimation(AMAP_ANIMATION_DROP)不适用，应改用movingMarker插件或自建requestAnimationFrame循环 - Mapbox GL：必须用
map.animateTo()或map.easeTo()，传入center和duration: 200，每次只动一帧
如果硬要自己写动画循环，注意：时间戳要用 performance.now()，不要用 Date.now()；插值参数 t 必须严格归一化到 [0,1]，否则会出现减速突变。
容易被忽略的边界问题：掉线重连和定位漂移怎么处理？
骑手手机锁屏、进隧道、切后台都会导致位置断发或乱跳。Workerman 无法感知这些，但可以靠数据逻辑兜底：
- 收到新点时，先算与上一点的球面距离（用
haversine公式），若 > 500 米且时间差 - 连接断开超过 30 秒，
onClose回调里清掉该骑手的$riders[$rider_id]，避免内存泄漏 - 重连后，前端应主动发
{type: "sync", rider_id: "R1001"}，服务端查 Redis 缓存的最新有效点（带时间戳），补推一次“锚点”，避免重连后 marker 突然闪现到旧位置
真正难的不是插值算法，而是区分“该平滑”和“该丢弃”的判断时机——GPS 噪声和网络抖动混在一起时，阈值设 300 米还是 500 米，得看城市路网密度和终端型号，没有银弹。
