Web Worker 处理百万级数据排序的核心是任务拆分、高效通信与渐进式 UI 反馈：Worker 纯计算、主线程仅调度；分块排序+归并降低延迟；添加 loading 状态与超时保护；优先使用 TypedArray 和复用 Worker 实例。
用 Web Worker 处理百万级数据排序，核心是把耗时的计算逻辑移出主线程，避免阻塞渲染和用户交互。关键不在“用不用 Worker”，而在于“怎么拆分任务 + 怎么通信 + 怎么不拖慢 UI”。
1. 用 Worker 承担纯计算，主线程只管调度和展示
排序本身（比如快速排序、归并排序）必须完全在 Worker 内完成，主线程不能参与比较或交换。Worker 接收原始数组（注意：需结构化克隆，不能传引用），执行完后把排序结果发回。不要在 Worker 里操作 DOM，也不要在主线程里循环等待结果。
- 主线程用
postMessage()发送数据，监听message事件接收结果 - Worker 中用
self.onmessage接收，self.postMessage()返回结果 - 大数据量建议先
JSON.stringify()+JSON.parse()预检是否可克隆，避免传入函数或 undefined 导致静默失败
2. 分块排序 + 归并，降低单次 Worker 延迟
百万级数组一次性排序仍可能让 Worker 卡住几秒（尤其低端设备），用户会感知“按钮点了没反应”。更稳的做法是分治：主线程把大数组切片（如每 5 万条一组），并发启动多个 Worker 或复用一个 Worker 分批处理，再在主线程归并已排序的子数组。
- 切片示例：
const chunks = Array.from({ length: Math.ceil(data.length / 50000) }, (_, i) => data.slice(i * 50000, (i + 1) * 50000)) - Worker 只负责对单个 chunk 排序，返回
{ index, sortedChunk }，方便主线程按序归并 - 归并可用双指针法，时间复杂度 O(n)，比重新全量排序快得多
3. 启动时加轻量反馈，避免用户误操作
即使用了 Worker，用户点击排序按钮后若无任何视觉反馈，仍会觉得“卡了”。应在 postMessage() 前立刻禁用按钮、显示 loading 微动效（如旋转图标或进度条），并在收到结果后恢复 UI。
立即学习“前端免费学习笔记（深入）”；
- 禁用按钮同时设
aria-busy="true"，提升可访问性 - 不推荐用百分比进度条——排序算法难以精确预估耗时；可用“分步指示”：如“正在分片 → 排序中（3/8）→ 归并中 → 完成”
- 超时保护：给 Worker 设置 10 秒 timeout，超时则报错并提示“数据量过大，建议筛选后操作”
4. 内存与性能细节不能忽略
百万级数字数组约占用 8MB（假设是 64 位浮点数），但若传的是对象数组（如 { id, name, value }），体积可能翻倍。传输本身有开销，频繁 postMessage 会拖慢整体速度。
- 优先传
TypedArray（如Float64Array）而非普通数组，Worker 可直接操作，零拷贝（配合transferable选项） - 排序算法选归并排序（稳定、最坏 O(n log n)），避开快排最坏 O(n²) 风险
- Worker 实例建议复用（
new Worker(...)一次，多次postMessage），避免反复创建销毁开销
不复杂但容易忽略：Worker 是解决假死的必要条件，但不是银弹。真正流畅的体验来自任务拆解、渐进反馈和合理降级——数据太大就提示筛选，排序中途允许取消，结果出来再批量更新列表（用 DocumentFragment 或虚拟滚动），这才是完整链路。
