JavaScript本质是单线程语言，其“多线程”仅通过Web Worker在浏览器中实现并行；异步非阻塞则依赖事件循环与任务队列，在单线程内调度I/O操作，二者原理不同、适用场景各异。
JavaScript 本身是单线程语言，没有原生多线程执行能力，所谓“多线程”只是通过 Web Worker 等机制在浏览器中模拟出的并行效果；而“异步非阻塞”则是它在单线程约束下，靠事件循环 + 任务队列实现的响应式编程模型——二者目标一致（不卡主线程），但原理和适用场景完全不同。
异步非阻塞：单线程里的调度智慧
它不新增线程，而是把耗时操作（如 fetch、setTimeout、addEventListener）交由浏览器或 Node.js 的宿主环境在后台线程中处理，主线程继续推进后续同步代码。等后台任务完成，回调函数被推入任务队列，待调用栈清空后，事件循环再将其拉入执行栈。
- 典型操作：网络请求、定时器、用户事件监听、文件读取（Node.js）
- 关键保障：所有回调都在主线程执行，所以 DOM 操作安全、状态可预测
- 局限性：无法真正并行计算——如果一个函数含 500ms 的 for 循环，它仍会阻塞渲染和交互
Web Worker：唯一合法的“多线程”方案
HTML5 标准定义的 Web Worker 允许你在主线程之外启动一个独立的 JavaScript 执行上下文，它拥有自己的全局对象、作用域和事件循环，与主线程完全隔离（不能访问 window、document、DOM）。
- 适合场景：图像处理、加密解密、大数据排序、物理模拟等 CPU 密集型任务
- 通信方式：只能通过 postMessage() 发送可序列化的消息，主线程用 onmessage 接收
- 注意点：Worker 启动有开销，不适合频繁创建销毁；小任务用异步反而更轻量
为什么 Promise 和 async/await 不等于多线程？
它们只是异步流程的语法糖和组织方式，底层依然依赖事件循环。一个 await 后面的 Promise.resolve() 或 fetch() 并不会开启新线程，只是把后续逻辑注册为微任务或宏任务，等待时机执行。
立即学习“Java免费学习笔记（深入）”；
- async 函数内部的 for 循环仍是同步阻塞的，不会自动“分片”或“移交控制权”
- 错误捕获、链式调用、语义清晰——这是它们的价值，不是并发能力的升级
- 想让长循环不卡页面？得手动拆成 setTimeout 分片，或移入 Worker
实际选择建议：看任务类型
判断一个任务该走异步还是 Worker，核心看它“吃 CPU 还是吃 I/O”：
- I/O 密集型（请求、读文件、监听）→ 用 fetch / Promise / async-await，足够高效
- CPU 密集型（百万数组排序、Canvas 像素遍历、RSA 加密）→ 必须用 Web Worker，否则必然卡顿
- 混合型（先请求数据，再本地大量处理）→ fetch 异步拿数据，再传给 Worker 处理
