小程序 Worker 适合处理什么任务？使用时有哪些限制？

简化版

小程序 Worker 适合把耗时的纯计算任务放到独立线程执行，例如数据解析、加解密、路径计算、复杂筛选等，避免阻塞逻辑层主线程。它不适合操作页面、调用大部分 UI API，也要注意通信成本、数据拷贝和生命周期清理。

详细版

Worker 的价值是把主线程压力挪走。小程序逻辑层如果长时间执行计算，可能导致事件响应慢、setData 延迟、页面交互卡顿。Worker 可以在后台线程计算，计算完成后通过消息返回结果。

适合：

大 JSON 解析后的二次计算。
图片或音频相关的轻量算法。
本地搜索、排序、路径规划。
加解密、签名、压缩等纯计算。

不适合：

直接更新页面视图。
调用依赖页面上下文的 API。
频繁传输巨大对象。
很短的小任务，因为通信成本可能大于收益。

完整版教学

一、Worker 解决的是主线程被计算堵住的问题

小程序逻辑层虽然和视图层分离，但逻辑层自己也有事件、请求回调、数据处理和 setData 调用。如果你在逻辑层连续执行 500ms 的同步计算，这段时间内用户点击、请求回调和后续逻辑都要等待。

Worker 的作用是把纯计算任务移到独立线程，让主逻辑继续响应用户操作。它不是让计算消失，而是把计算从关键交互路径移开。

主逻辑线程：用户事件、请求回调、setData
Worker：排序、解析、加密、路径计算
两者通过 postMessage 通信

二、不是所有任务都值得放 Worker

Worker 有创建成本和通信成本。如果任务只需要 2ms，放到 Worker 可能因为消息传递花 5ms，反而更慢。适合放 Worker 的通常是耗时明显、输入输出结构清晰、不依赖 UI 的任务。

数字例子：本地搜索 5000 条数据，每次输入都同步过滤需要 80ms，用户输入会卡；放到 Worker 后主线程只负责发关键词和接收结果，交互更顺。但如果只有 50 条数据，过滤耗时 1ms，就没必要复杂化。

任务	是否适合 Worker	原因
5000 条本地搜索	适合	计算明显，结果清晰
按钮点击改状态	不适合	UI 相关且很轻
加密大文本	适合	纯计算
调用弹窗 API	不适合	依赖页面上下文

三、通信模型决定了数据要小

Worker 和主线程通过消息通信。传递大对象会产生序列化或拷贝成本，频繁传递更会抵消 Worker 的收益。设计时要尽量传递必要字段，而不是每次把整个页面状态发过去。

例如一个商品列表 10000 条，每条 1KB，整体就是约 10MB。如果每次输入都传 10MB 给 Worker，通信成本会非常高。更好的做法是 Worker 初始化时接收一次数据，后续只传关键词。

// 主线程
worker.postMessage({ type: 'search', keyword: '耳机' })

// Worker
worker.onMessage((msg) => {
  if (msg.type === 'search') {
    worker.postMessage({ type: 'result', list: search(msg.keyword) })
  }
})

四、Worker 不能替代视图层优化

如果页面卡顿的根因是 setData 传输太大、节点太多、图片太重，把计算放 Worker 并不能解决渲染瓶颈。Worker 只处理逻辑计算，不负责视图渲染。

比如长列表 3000 个节点同时渲染，卡在节点创建和布局上；即使列表数据由 Worker 生成，最终 setData 传输和视图更新仍然重。此时要分页、虚拟列表或减少节点，而不是只加 Worker。

五、生命周期要及时终止

Worker 会占用资源。页面卸载后如果不终止，可能继续计算或保留内存。尤其是多个页面都创建 Worker 时，重复实例会导致性能下降。应该在页面不需要时明确停止，或者设计全局单例并管理引用。

工程上常见策略是：页面进入时创建，任务完成或页面卸载时 terminate；长生命周期计算则放在应用级统一管理，并避免多个页面重复创建同类 Worker。

六、错误和超时也要设计

Worker 内部计算可能抛错，也可能因为输入异常长时间不返回。主线程不能无限等待。可以给每个任务分配 requestId，并设置超时；Worker 返回时带上 requestId，主线程只处理当前有效任务。

主线程发送任务 #42
  ├─ 3 秒内收到结果：更新页面
  ├─ 收到错误：展示失败
  └─ 超时：取消等待并允许重试

记忆钩子：Worker 优化的是“逻辑计算阻塞”，不是“所有卡顿”；卡在渲染和通信时，要回到 setData 和节点数优化。

七、常见误区与追问

误区：用了 Worker 页面一定不卡。 如果瓶颈是渲染、图片或 setData，Worker 帮助有限。
误区：任何计算都应该放 Worker。 小任务通信成本可能超过计算成本，没必要复杂化。
误区：Worker 可以直接操作页面。 Worker 不适合调用 UI 和页面上下文相关 API，只做独立计算。
追问：如何判断是否需要 Worker？ 用开发者工具测同步计算耗时，明显阻塞交互且逻辑独立时再使用。
追问：大列表搜索怎么设计？ Worker 初始化时接收数据，后续只传关键词和返回必要结果，减少通信体积。
追问：页面退出时 Worker 怎么处理？ 终止实例或减少引用，避免后台继续计算和内存泄漏。

八、加强记忆

Worker 用“纯计算、少通信、管生命周期”来记。它适合重计算但不适合 UI 操作；任务要足够重才值得拆出去，传输数据要尽量小，页面卸载要清理。面试中把它和 setData、长列表渲染区别开，是这题的关键。

简化版

详细版