必须将原始经纬度转换为bd09ll坐标系后再传给百度地图，否则bmap.point会报错或轨迹跳变；前端需根据coord字段判断是否转换，后端建议批量调用百度坐标转换api，websocket断连时应缓存断点并按时间戳补全轨迹。
直接用 WebSocket 传原始经纬度给百度地图，bmap.Point 会报错或轨迹跳变——因为百度地图只认 bd09ll 坐标系，而 GPS/手机定位默认返回的是 wgs84 或 gcj02。必须在传输前或接收后做坐标转换，否则小车“瞬移”是常态。
WebSocket 发送前必须转成 bd09ll 坐标
后端或前端拿到设备原始经纬度（比如 {lat: 34.091878, lng: 113.858795}），不能直接塞进 bmap.Point。百度地图 JS API 不接受 wgs84 或 gcj02 坐标，强行使用会导致点位偏移几百米甚至跨街区。
- 若设备端能输出
bd09ll（部分车载终端支持配置），优先让硬件层转换，省去中间环节 - 若只能输出 wgs84（如浏览器
navigator.geolocation），前端必须调用百度官方转换接口：BMap.Convertor.translate()，注意它异步、有调用频率限制，不适合高频轨迹点 - 更稳妥的做法：后端统一转换。用百度提供的服务端坐标转换 API（
http://api.map.baidu.com/geoconv/v1/?coords=lng,lat&from=1&to=5&ak=YOUR_AK），from=1表示 wgs84，to=5表示 bd09ll - 批量转换时别拼单个 HTTP 请求，把点攒够 10–20 个再发一次批量请求，避免触发限流（默认 100 次/天免费，商用需申请配额）
前端接收 WebSocket 数据后，别直接 new BMap.Point
收到 WebSocket 消息后，常见错误是直接 new BMap.Point(data.lng, data.lat)。只要坐标系不对，画出来的线就是歪的，尤其在郑州、西安等城市边缘偏差明显。
百度热榜监控 | Baidu Hot Monitor
下载
百度热榜监控 | Baidu Hot Topics Monitor. 获取百度热搜榜、搜索趋势、关键词热度 | Get Baidu trending searches, trends, keyword popularity. 触发词：百度、热搜、baidu.
- 确保 WebSocket 消息体里明确标注坐标系，例如：
{"lat":34.091878,"lng":113.858795,"coord":"bd09ll"}，前端根据coord字段决定是否跳过转换 - 如果后端已转好，前端可直接用：
new BMap.Point(data.lng, data.lat)；如果没转，必须走BMap.Convertor.translate回调后再创建点 - 不要在
translate回调里反复调用polyline.setPath()——高频更新时会造成重绘卡顿，应先缓存点数组，每 3–5 个点合并更新一次路径 - 注意
BMap.Convertor是全局单例，首次调用需等BMap加载完成，建议在onload回调里初始化转换器
WebSocket 连接断开时，轨迹线别“抽搐”
网络抖动或页面切后台时，WebSocket 可能短暂断连。若前端没做状态管理，重连后一股脑 push 所有积压点，小车会从起点“闪现”到终点再继续跑。
- 后端推送消息时带上时间戳字段
ts（毫秒级），前端按ts排序再插入轨迹数组，避免乱序 - 连接断开期间，前端暂停添加新点，但保留最后 3 个有效点作为“断点锚点”；重连后先请求一次最近 10 秒的历史轨迹补全缺口
- 用
socket.readyState === WebSocket.OPEN做发送守门员，别在CLOSING或CLOSED状态下还往里塞数据 - 百度地图的
BMap.Polyline不支持动态删点，所以补点逻辑得自己维护数组，再整批setPath
最易被忽略的一点：百度地图的 enableScrollWheelZoom(true) 和 centerAndZoom 在 WebSocket 高频更新时会抢夺渲染资源，导致轨迹线绘制延迟。建议轨迹播放期间临时禁用滚轮缩放，或改用 panTo 平滑跟随，而不是每次都重设中心点和缩放级别。
