微信小程序中uni-app的map组件必须使用原生渲染模式，设style="width:100%;height:100%;"且platform="weixin"自动启用原生层，否则marker不显示、点击无响应、缩放卡顿。
微信小程序地图组件 map 在 uni-app 中必须用原生渲染模式
uni-app 的 map 组件在微信小程序平台不支持 custom-style 或 canvas 渲染，必须设为 style="width: 100%; height: 100%;" 且使用原生 map（即 platform="weixin" 下自动启用原生层）。否则 marker 不显示、点击无响应、缩放卡顿。
常见错误：在 H5 或 App 端调试时用了 cover-view 套 map，切到微信小程序后 marker 全部消失——这是因为微信原生 map 不支持子节点覆盖，所有 cover-view/cover-image 必须写在 map 标签外部并用 bindmarkertap 关联。
- 必须显式设置
longitude和latitude，不能只靠show-location -
markers数组中每个对象至少包含id、latitude、longitude、name - 自定义 icon 需用本地路径（如
/static/icon-store.png），网络地址无效 - marker 点击事件用
@markertap，参数是detail.markerId，不是event.target.id
uni.getLocation 获取用户位置后，别直接传给 map 的 center-location
微信小程序返回的坐标是 GCJ-02（国测局加密坐标），而腾讯地图 SDK 默认使用 GCJ-02，但 uni-app 的 map 组件底层调用的是微信原生 map，它对坐标系处理较严格：若你用高德/百度 API 查附近门店，返回的是 WGS-84 或 GCJ-02，混用会导致偏移 300–500 米。
解决办法只有两个：
- 统一用腾讯位置服务（
https://apis.map.qq.com/ws/geocoder/v1/）查逆地理+周边，它返回的坐标与微信map原生一致 - 如果必须用高德，需调用高德的「坐标转换」API（
https://restapi.amap.com/v3/conv/coord）把 WGS-84 转 GCJ-02，再喂给map -
uni.getLocation({ type: 'gcj02' })是微信小程序唯一可靠方式，type: 'wgs84'在真机上常为空或偏差极大
动态更新 markers 时，id 必须是数字且全局唯一
微信原生 map 对 marker 的 id 类型极其敏感：字符串 ID（如 "store_123"）会导致部分机型无法触发 markertap，iOS 尤其明显；重复 ID 会让新 marker 覆盖旧的，但点击仍响应旧数据。
实操建议：
- 生成
id用index或后端返回的整型主键（如store.id），避免拼接字符串 - 每次 setData 更新
markers前，先用JSON.parse(JSON.stringify(markers))深拷贝，否则微信内部引用缓存可能导致 marker 不刷新 - 不要在
markers里塞大对象（如完整门店详情），只保留必要字段，否则影响渲染性能 - 超过 10 个 marker 时，建议加
callout配置控制气泡显示逻辑，避免屏幕拥挤
附近门店搜索结果太多？用 region + scale 控制地图视野，别依赖 polygons
微信 map 不支持 polygons 渲染热力图或区域面，也没法像高德那样直接传半径查“500 米内门店”。真实做法是：先用 uni.getLocation 拿到用户坐标，再调腾讯 POI 接口（https://apis.map.qq.com/ws/place/v1/search）带 location 和 radius 参数拉数据，然后手动过滤。
关键点：
- 接口返回的
result里每个 poi 的location.lat/location.lng可直接当 marker 坐标用 - 前端别用欧氏距离算“附近”，要用球面距离公式（如 haversine），否则跨纬度误差爆炸
- 地图
scale设为 14～16 较合理（14 ≈ 1km 视野，16 ≈ 200m），太小看不到全貌，太大 marker 挤成点 - 用户拖动地图后，可通过
@regionchange监听detail.type === 'end'，再重新请求该视野范围内的门店（需自己算 bounding box）
真正难的不是画点，而是坐标系对齐、视野联动和防抖请求——这些地方一漏，地图就“看起来能用，实际总偏”。
