UD5工具箱
基础概念问题
Q: Web Worker 和 Web Worker 线程池有什么区别？
A: Web Worker 是单个后台线程的概念，每次 new Worker() 创建一个独立的线程。线程池是一种设计模式，预先创建多个 Worker 并维护一个任务队列，将任务分发给空闲的 Worker 执行。线程池避免了频繁创建和销毁 Worker 的开销，并限制了同时运行的 Worker 数量以防止资源耗尽。本工具使用的是单个 Worker 的简单模式，实际项目中对于需要并发处理大量任务的场景，可以实现线程池模式。
Q: Worker 可以操作 DOM 吗？为什么不能？
A: Worker 不能操作 DOM。原因是 Worker 运行在独立的线程中，而 DOM 操作必须在主线程上执行以保证线程安全。如果允许多个线程同时操作 DOM，会产生竞态条件导致页面状态不一致。Worker 的设计哲学是专注于计算任务，通过消息传递将计算结果发回主线程，由主线程完成 DOM 更新。这种分工明确的架构既保证了线程安全，又提升了性能。
Q: 创建多个 Worker 是否能线性提升性能？
A: 不一定。性能提升取决于任务的性质和硬件条件。对于可以完全并行的独立计算任务，Worker 数量不超过 CPU 核心数时，性能提升接近线性。但当 Worker 数量超过核心数时，操作系统需要在线程之间进行上下文切换，反而会增加开销。此外，Worker 之间的通信开销、数据同步开销也会影响实际的性能收益。
实际应用问题
Q: 什么时候不值得使用 Web Worker？
A: 以下情况使用 Worker 可能不值得：计算任务执行时间很短（小于 16ms），此时创建 Worker 和消息传递的开销可能超过节省的主线程时间；需要频繁与主线程通信的任务，序列化和反序列化的开销可能抵消计算节省的时间；需要直接操作 DOM 的任务，Worker 无法满足需求。在这些情况下，使用 requestIdleCallback 或任务分片可能更合适。
Q: Worker 脚本文件应该如何组织？
A: Worker 脚本必须通过独立的 URL 加载，不能内联在 HTML 中。常见的组织方式有：单独的 JS 文件（如 worker.js）、通过 Blob URL 动态创建（适合简单 Worker）、使用 Webpack 等构建工具打包。对于需要使用 npm 包的 Worker，推荐使用 worker-loader 或 new Worker(new URL('./worker.js', import.meta.url)) 等工具链支持的方式。生产环境中的 Worker 脚本应该进行压缩和缓存优化。
Q: 如何调试 Worker 中的代码？
A: 主流浏览器的开发者工具都支持 Worker 调试。在 Chrome DevTools 中，可以通过 Sources 面板的 Workers 标签页查看和调试运行中的 Worker。可以在 Worker 代码中设置断点、添加 console.log 输出、查看变量状态。Worker 中的 console.log 输出会显示在控制台中，带有 Worker 的标识前缀。对于生产环境的 Worker 错误，可以通过 Worker 的 onerror 事件处理器捕获并上报。
Q: 数据量多大时 Worker 的通信开销不可忽略？
A: 通信开销取决于数据类型和大小。对于简单的数值和小型对象（小于 1KB），序列化和反序列化的耗时通常在微秒级别，可以忽略不计。对于大型数组和复杂对象（大于 1MB），通信开销可能达到毫秒级别。一般建议：如果计算时间大于通信开销的 10 倍以上，使用 Worker 是值得的。可以使用 Performance.now() 在实际项目中测量通信开销来做出判断。
Q: Web Worker 在移动端浏览器中的支持情况如何？
A: Web Worker 在所有现代移动浏览器中都有良好的支持，包括 iOS Safari、Android Chrome、Firefox for Android 等。但移动端设备的 CPU 核心数和性能有限，需要更加谨慎地控制 Worker 的数量和计算量。建议在移动端使用更小的数据规模和更少的 Worker 数量，并关注内存使用情况。移动端浏览器在后台标签页时可能会暂停 Worker 的执行以节省电量。