不能直接用 Worker 实现路径规划，因HTML5无地理计算能力且贪心算法无法应对路网复杂约束；Worker 应用于SDK调用前后的预处理与后处理任务，如坐标清洗、结果聚合、缓存匹配等。
不能直接用 Worker 实现路径规划——HTML5 本身不提供地理计算能力，贪心算法也解决不了真实路径规划问题。所谓“Worker + 贪心算法 = 高性能路径规划”是一种常见误解。
为什么贪心算法不适合真实路径规划
贪心算法在每一步只选当前最优局部解（比如离终点最近的邻接点），但城市路网存在绕行、单行道、禁行区、实时拥堵等复杂约束。它无法回溯，极易陷入死胡同或绕远路。Dijkstra 或 A* 才是标准图搜索算法；而高德、百度等 SDK 内部用的是更复杂的混合策略（含启发式剪枝、多源扩展、历史路况建模），不是简单贪心。
实际中，连“最短时间”都难靠贪心逼近——你没法仅凭经纬度差判断哪条路更快，必须查真实路网拓扑与动态权重。
Worker 的合理角色：加速已有 SDK 的预处理或后处理
Worker 不参与路线计算本身，但可承担 SDK 调用前后的高开销任务：
立即学习“前端免费学习笔记（深入）”；
- 坐标批量清洗：将用户上传的 1000 个 GPS 原始点（含漂移、重复、无效值）在 Worker 中做去噪、聚类、抽稀，再传给地图 SDK —— 主线程不卡顿
- 结果轻量聚合：SDK 返回多条备选路线后，在 Worker 中并行计算每条路线的“通勤舒适度分”（基于坡度变化、红灯数估算、收费路段占比等自定义指标），避免阻塞 UI
- 离线缓存匹配：把历史高频起终点对（如“公司→家”）对应的最佳路线缓存在 IndexedDB，Worker 在后台比对新请求是否命中缓存，命中则秒级返回，不触发网络请求
Worker 调用地图 SDK 的关键限制
地图 SDK（如 AMap、BMap）的 JavaScript API 必须运行在主线程，因为它们依赖 DOM 元素（地图容器）、window 对象、以及浏览器定位接口。Worker 里调用 AMap.Geocoder 或 AMap.DirectionsDriving 会直接报错。
正确做法是：
- 主线程发起
driving.search()，拿到原始路线数据 - 把
result.routes数组发给 Worker - Worker 处理完附加计算（如耗时重估、POI 密度分析），再把增强版结果发回
一个可行的结构示例
假设你要为物流调度页快速筛选“3 小时内可达客户”：
- 主线程获取司机当前位置，调用高德
Driving.search查询到所有客户点的预计到达时间 - 将返回的 200 条
route对象（含 time、distance、steps）打包发送至 Worker - Worker 中启动 4 个并行子任务：分别校验时效性、标记高速占比、过滤限行时段、叠加天气影响系数
- Worker 汇总后返回带标签的客户列表（如
{id: 'c102', reachable: true, risk: 'low'}），主线程渲染地图标记
这样既利用了 Worker 的并发算力，又没越界调用地图能力，真正提升的是“决策链路”而非“路径生成”本身。
