题目重点：异步等待与并行CPU计算不同，Worker结果仍需与当前请求对齐。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 浏览器UI主线程与Web Worker是不同执行环境；不把Promise/async自动等同另一个线程。
- Worker没有页面DOM，训练用它做CPU解析/计算；网络等待本身通常不需搬到Worker。
解题路线
- UI事件/render保持主线程，长CPU任务可交Worker。主线程发request ID和输入，Worker回结果/error，再由主线程更新state；旧request结果要丢弃或存回正确对象。
- 消息一般structured clone，Transferable可以转移buffer所有权减少复制，转移后发送方不能继续按旧buffer使用。共享内存需显式同步，普通message逻辑并不要求ShareArrayBuffer。
- 取消CPU任务不能只abort一个fetch；可用Worker协作检查取消信号、按chunk执行，或terminate并重新建worker。避免用一个长期不可中断循环占满worker且假装cancel已生效。
- 小任务搬运/启动成本可能大于计算收益，按测量选择。维护有限worker pool、队列上限和背压，不能每个token建一个worker。
手动走一遍
大文档解析使页面卡顿，可把解析搬Worker；只有I/O等待的聊天请求async已经能让UI继续响应。用户切请求后Worker回旧结果，按request ID确认后再写state，不能无条件覆盖当前图表。
规模与取舍
计算工作仍O(input size)，并行受CPU核数/内存带宽约束；clone/transfer和worker启动是额外成本。队列需设上限避免高输入速率无界积压。
易错点与追问
容易失分的边界
- Promise包装同步大循环并没有离开主线程。
- Worker中直接操作DOM。
继续深挖
- 任务拆分与结果合并怎样减少通信开销？
- 共享buffer时怎样用同步防止读到半完成结果？
技术参考
- MDN Web Workers：技术语义参考，具体题目按本文约定。
