小程序 map 组件 marker 超 300 个极易内存溢出或主线程卡死，因微信原生限制每个 marker 创建独立视图节点；需显式设置 joincluster: true、id 字段，并配合服务端分页与客户端聚合。
直接说结论：小程序端 map 组件 Marker 超过 300 个就极大概率触发内存溢出或主线程卡死，不是“卡顿”，是真·死机（白屏、无响应、进程被系统回收）。这不是 uni-app 的 bug，而是微信原生 map 组件的硬性限制——它对每个 marker 都创建独立原生视图节点，iOS 上单页超 500 个 marker 几乎必崩，Android 也撑不过 800 个。
为什么 joinCluster 在小程序里必须显式开启
uni-app 的 <map></map> 组件在小程序平台底层调用的是微信 map 原生组件，而微信从基础库 2.10.0+ 才正式支持点聚合（cluster 属性），但 uni-app 默认不启用。如果你没手动设 joinCluster: true，哪怕数据里写了 cluster 字段，也不会生效。
-
markers数组中每个对象必须带id字段（数字或字符串均可，但不能重复） - 必须在
<map></map>标签上显式绑定:joinCluster="true"，仅靠数据字段无效 - 微信开发者工具里点聚合常失效（需双击才分离），但真机上点一下就能展开，务必在 iOS/Android 真机测试
- 聚合样式不可自定义（微信强制使用蓝底白字圆点），想换图标或颜色得自己实现 JS 聚合逻辑 +
customCallout
regionchange 节流不当反而加重死机
很多人用 @regionchange 动态加载可见区域 marker，但没做节流控制，结果用户一拖地图就连续触发 10+ 次请求 + 重赋值 markers，Vue 的响应式更新和小程序 setData 频繁调用直接压垮主线程。
- 必须用
setTimeout或lodash.throttle限制regionchange处理频率，建议最小间隔 ≥ 300ms - 只在
event.type === 'end'时才执行数据加载（拖动/缩放结束才更新，避免中间态） - 新 marker 数据要跟旧数据做浅比较，
JSON.stringify(new) !== JSON.stringify(old)再赋值，避免无意义 setData - 后端接口必须支持按矩形范围（sw / ne 坐标）查询，不能返回全量再前端过滤
频繁更新 marker 导致内存泄漏的隐藏陷阱
死机不总发生在首次加载，更多见于长期运行后——比如配送员页面每 10 秒刷新一次 marker 位置，setInterval 不清理，markers 数组不断 push 新对象却没清空旧引用，V8 引擎无法 GC，内存持续飙高直至系统杀进程。
- 每次更新前先清空旧定时器：
clearInterval(this.markerTimer)，再新建 - 不要用
this.markers.push(...newData)，改用this.markers = newData确保旧数组可被回收 - 若 marker 含函数或闭包（如
clickHandler），必须用箭头函数或绑定 this，否则形成强引用链 - 页面卸载时（
onUnload）务必清除所有 timer 和 event listener，uni-app 不自动帮你清理
最易被忽略的一点：点聚合只解决渲染压力，不解决数据传输和内存占用。哪怕只显示 20 个聚合点，如果后端一次性返回 5000 条原始坐标并全塞进 markers 数组，JS 堆内存照样爆。真正安全的做法是——服务端分页 + 客户端聚合，两者缺一不可。
