微信小程序map中polyline不显示,需确保polyline为数组且每项含points(latitude/longitude对象)、8位hex color、width数字;轨迹点超1000需抽稀或分段;width应随scale动态调整;坐标系须统一为gcj-02。

微信小程序中 polyline 不显示?先确认 map 组件的 show-location 和 polyline 数据格式
uni-app 编译到微信小程序时,map 组件的 polyline 属性必须是数组,且每个 polyline 对象必须包含 points(经纬度数组)、color(十六进制带 alpha,如 #FF0000AA)、width(数字,单位 px),缺一不可。常见错误是传了字符串颜色(如 "red")或漏了 points 的 latitude/longitude 字段名——微信原生要求严格命名,不接受别名。
实操建议:
-
points必须是形如[{latitude: 39.9, longitude: 116.4}, ...]的对象数组,不能是[39.9, 116.4]或{lat: ..., lng: ...} -
color必须为 8 位 hex(如#FF000080),4 位(#F008)不支持,rgb/rgba 字符串会静默失败 - 若 polyline 动态更新,需确保每次 setData 都传完整 polyline 数组,不能只改其中某一项的 points —— 微信 map 组件不支持局部 diff
轨迹点太多导致卡顿或绘制失败?用抽稀 + 分段渲染
微信小程序 map 组件对单条 polyline 的点数有限制(实测超 1000 点易触发渲染异常或白屏),而运动轨迹原始数据常达数千点。直接全量传入不仅卡,还可能被截断。
实操建议:
- 前端做 Douglas-Peucker 抽稀(推荐用
fast-douglas-peuckernpm 包),阈值设 3–5 米,可压缩 60%+ 点数且视觉无损 - 若仍需高精度回放,拆成多条 polyline,每条控制在 300 点以内,并用
zIndex控制叠加顺序(避免后画的盖住前画的) - 避免在
onReady后立刻 setData 大量 polyline;可加setTimeout(() => { this.setData(...) }, 100)让 map 初始化完成再绘
轨迹线不随地图缩放自适应粗细?别依赖 width 的绝对像素值
polyline.width 是逻辑像素(px),在不同缩放级别下视觉粗细变化明显:放大后变细、缩小后糊成一片。这不是 bug,是微信 map 渲染机制决定的。
由于微信的大热,为了更好的方便使用微信的用户查询一些信息,这篇文章是入门级的微信公众平台开发教程,需要的朋友可以参考下 这篇入门教程将引导你完成如下任务: 创建百度云平台应用启用微信公众平台开发模式获取订阅、文字、图片、语音、视频消息回复文本、图文及音乐消息程序开发
实操建议:
- 不要把
width设成固定值(如8);根据scale动态计算:width: Math.max(2, Math.min(12, 10 / scale)) - 监听
bindregionchange事件获取当前scale,但注意该事件频繁触发,需节流(如 lodash 的throttle或简单时间戳判断) - 更稳妥的做法是:只在用户停止拖拽/缩放 300ms 后重新 setData polyline,避免高频重绘
真机调试发现轨迹偏移?检查坐标系是否统一为 GCJ-02
微信小程序 map 默认使用国测局加密坐标系(GCJ-02),而你采集的 GPS 原始数据(WGS-84)或第三方 SDK 返回的坐标若未经转换,直接绘制会导致几百米级偏移——尤其在城市区域明显。
实操建议:
- 所有轨迹点必须经 WGS-84 → GCJ-02 转换,可用
gcoord库:gcoord.transform(points, gcoord.WGS84, gcoord.GCJ02) - uni-app 中不能直接用
navigator.geolocation,应调用uni.getLocation({type: 'gcj02'})获取原生 GCJ-02 坐标,避免二次转换出错 - 若用蓝牙设备或外接 GPS 模块,务必确认其输出坐标系,WGS-84 必须转,BD-09(百度)需先转 WGS-84 再转 GCJ-02
真正麻烦的是坐标系混用——比如起点用 uni.getLocation(gcj02),途中点用某运动 SDK 返回的 wgs84,又没转换,整条线就斜着飘出去了。这种问题在模拟器里看不出来,只有真机跑才暴露。










