Web Worker在离线地图渲染中专用于纯CPU密集型地理计算，如瓦片索引、坐标转换、PBF解码裁剪、空间分析等，需满足无DOM依赖、输入输出可序列化或通过ArrayBuffer零拷贝传输。
离线地图渲染中，Web Worker 主要用来把原本卡在主线程的耗时计算任务移出去，比如瓦片坐标转换、几何计算、路径简化、缓冲区生成、矢量数据解码或投影变换。这些操作不涉及 DOM，但 CPU 消耗高，放主线程会直接导致地图拖拽卡顿、缩放延迟、UI 响应失灵。
哪些地图计算适合丢进 Worker
不是所有地图逻辑都适合 Worker，核心判断标准是：纯数据计算、无 DOM 依赖、输入输出可序列化（或能用 ArrayBuffer 高效传递）。
- 瓦片索引计算：根据经纬度 + 当前缩放级别，算出 XYZ 或 TMS 对应的 x/y/z 值。看似简单，但在高频拖拽中反复调用，积少成多也会占满主线程。
- 地理坐标系转换：WGS84 ↔ Web Mercator（EPSG:3857）的批量点位转换，尤其处理上千个轨迹点时，Math 运算密集，Worker 能稳住帧率。
- GeoJSON 矢量瓦片解码与裁剪：离线包里常存的是 PBF 格式矢量瓦片，解码（protobuf 解析）、反序列化为 GeoJSON、再按视口范围做空间裁剪，全部可在 Worker 中完成，只把最终精简后的要素数组传回主线程。
- 前端空间分析：比如点击某区域后，在 Worker 中实时计算其内部所有 POI 的聚类中心、生成 Voronoi 图、或做点面包含判断——这些运算不依赖渲染，但结果要快速反馈给地图图层。
怎么传数据：避免 JSON 序列化瓶颈
离线地图数据动辄几 MB，用 postMessage 传普通对象会触发结构化克隆，慢且内存翻倍。推荐组合方案：
- 用 ArrayBuffer 传原始二进制数据（如 PBF 瓦片字节流、Float32Array 存储的坐标点），Worker 接收后直接 new Uint8Array(buffer) 或 new Float32Array(buffer) 处理；
- 用 Transferable Objects：发送时加 transfer 参数，把 ArrayBuffer 所有权移交 Worker，主线程立刻释放内存，零拷贝；
- 元信息（如 zoom、bounds、投影参数）仍可用普通对象传，体积小、开销可忽略。
Leaflet/Vue 地图中 Worker 的典型协作流程
以 Vue + Leaflet 渲染本地瓦片为例，主线程只管“调度”和“绘制”，Worker 只管“算”：
立即学习“Java免费学习笔记（深入）”；
- 用户拖动地图 → 触发 moveend → 主线程收集当前视口 bounds 和 zoom；
- 主线程把 bounds、zoom、以及预加载的瓦片二进制 buffer（从 IndexedDB 读取）打包，postMessage 发给 Worker；
- Worker 解析 PBF、转坐标、裁剪出落在视口内的要素、生成简化后的 GeoJSON 特征集合；
- Worker 将结果（轻量 GeoJSON 或自定义二进制结构）通过 postMessage 回传，主线程用 L.GeoJSON 或自定义 CanvasLayer 渲染；
- 关键点：整个过程主线程没执行任何循环或 Math.atan2，滚动始终丝滑。
注意 Worker 不能做的事
Worker 是纯计算沙箱，以下操作必须留在主线程：
- 调用 leaflet.map.setView()、L.marker().addTo(map) 等任何涉及 DOM 或地图实例的方法；
- 读写 localStorage、访问 document 或 window 对象；
- 直接绘制 canvas —— 但可以生成 ImageBitmap 后传回，主线程用 ctx.drawImage() 渲染；
- 发起 fetch 请求（Service Worker 才负责网络代理，专用 Worker 不行）。
