web worker 提供真正并行执行路径，解决计算阻塞主线程问题；主线程异步机制（promise等）仅实现单线程内协作调度，无法加速纯计算。
Web Worker 不提供“并发控制”能力，它提供的是真正的并行执行路径，而 JavaScript 主线程的异步机制（Promise、async/await、事件循环）提供的是单线程内的任务调度与协作能力。两者不是同一维度的概念，不能简单比较“谁更并发”，而是分工明确、各司其职。
Web Worker 解决的是“计算不卡主线程”
它在浏览器中创建一个独立的 JavaScript 执行环境，拥有自己的调用栈、堆内存和全局对象（self 而非 window）。这个线程与主线程物理隔离：
- 无法访问 DOM、
document、localStorage、fetch（除非显式启用）、setTimeout等主线程专属 API - 通信唯一方式是
postMessage+onmessage，数据默认结构化克隆（深拷贝） - 支持
Transferable（如ArrayBuffer），可实现零拷贝传输，大幅提升大数据量交换效率 - 即使 Worker 内运行
while(true)，主线程依然能滚动、响应点击、播放动画
主线程的“并发”其实是事件循环驱动的协作调度
JavaScript 主线程始终是单线程的，所谓“并发请求”或“同时处理多个 Promise”，本质是：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 把 I/O 操作（如网络请求、定时器）委托给浏览器内核其他线程执行
- 主线程立即返回，继续执行后续同步代码
- 当底层操作完成，回调被推入宏任务队列（
setTimeout）或微任务队列（Promise.then） - 事件循环按规则依次取出：一个宏任务 → 清空全部微任务 → 可选渲染 → 下一个宏任务
这种模型擅长掩盖 I/O 延迟，但对纯计算毫无帮助——Promise.all([fib(40), fib(41), fib(42)]) 不会变快，反而因同步执行三遍而更慢。
混合使用才是现代 Web 应用的典型模式
高性能应用往往让两类机制协同工作，各尽所长：
- 主线程：负责用户交互、UI 渲染、发起请求、接收并更新 DOM
- Worker：接收原始数据（如 ArrayBuffer 图像像素、JSON 日志流、加密密钥），做解析、滤镜、排序、压缩、模拟等重计算，再将轻量结果（如坐标数组、摘要字符串）传回
-
通信设计：避免高频小消息；批量处理后一次性返回；敏感数据用
Transferable避免拷贝；任务结束及时worker.terminate()
别误把 Promise.all 当成并行加速器
Promise.all([fetch(a), fetch(b)]) 的“并发”仅体现在网络请求发起阶段，由浏览器网络栈并行处理；JS 层并未多线程执行，只是同时注册了两个待完成的异步任务。一旦响应到达，解析 JSON 或处理 blob 仍发生在主线程上——这部分若耗时，照样卡顿。真正要提速，得把解析逻辑也放进 Worker。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
