在 Web 开发中，绝大部分时间其实都花在“等待”上——等待数据库返回查询结果，等待第三方 API 的响应，等待用户点击按钮，等待文件读写完成。真正属于自己的代码执行时间往往微乎其微。JavaScript 的异步非阻塞模型，正是为这种 I/O 密集型场景量身打造的工作方式。
同步阻塞的困境
为了理解异步非阻塞的价值，不妨先看看传统的同步阻塞模型。假设一个服务端程序用同步方式处理三个请求，每个请求需要查询一次数据库（耗时 100ms）：
请求1 → 等数据库100ms → 返回
请求2 → 等数据库100ms → 返回
请求3 → 等数据库100ms → 返回
总耗时：300ms，且等待期间线程完全空闲为了提升并发能力，传统的做法是开多个线程，每个线程处理一个请求。但线程数量有上限，线程切换也有不小的开销，当并发请求成千上万时，系统资源会被迅速耗尽。
异步非阻塞的思路
JavaScript 采用单线程事件循环模型，遇到 I/O 操作时不会原地等待，而是立即发起请求并注册一个回调函数，然后继续处理下一个任务。当 I/O 操作完成后，回调函数被放入任务队列，等待主线程空闲时执行。
发起请求1（注册回调A）→ 发起请求2（注册回调B）→ 发起请求3（注册回调C）
→ 100ms后，数据库返回结果 → 依次执行回调A、B、C
总耗时：约100ms，期间主线程可以继续接收新请求这种模式让单个线程能够高效处理海量并发连接。一个 Node.js 进程，即使只有单线程，也可以轻松管理上万个同时存在的网络连接，而内存占用远低于为每个连接创建独立线程的传统方案。
浏览器端：永不卡死的用户界面
异步非阻塞模型同样深刻影响着浏览器端开发。如果 JavaScript 在发起网络请求时采用同步阻塞，页面会在等待期间完全冻结——按钮点击无响应，动画卡顿，用户体验极差。而实际上，浏览器中的 fetch、XMLHttpRequest、setTimeout、事件监听等 API 都是异步的，保证主线程可以持续响应用户操作。
例如，当用户快速连续点击“加载更多”按钮时，异步请求不会相互阻塞，页面依然流畅。当然，这也可能带来竞态问题（后发起的请求先返回），需要使用 AbortController 取消请求或通过标识位忽略过期响应，这些在第 12 章异步编程体系中有详细讨论。
实际收益：高并发与低成本
异步非阻塞模型带来的优势非常直观：
- 高吞吐量：单线程即可管理大量 I/O 操作，特别适合构建聊天服务器、实时数据推送、API 网关等需要同时维持大量连接的场景。
- 低成本：相比需要成百上千个线程的同步服务器，Node.js 可以用很少的系统资源完成同等规模的任务，节省服务器成本。
- 代码心智负担低：没有多线程的锁、竞态、死锁等问题，开发者只需关注回调或 Promise 链的逻辑顺序。
不是银弹：CPU 密集型任务的短板
必须诚实地说，这种模型在处理 CPU 密集型任务（如大规模数学计算、图像处理、视频编码）时优势不再。因为单线程在执行计算时无法处理其他任务，一个耗时 3 秒的循环会让整个服务停止响应 3 秒。解决方案是借助 Web Worker（浏览器端）或 Worker Threads（Node.js）将计算任务分流到其他线程，而不是在异步模型本身上硬扛。
但即便如此，Web 应用的典型负载——频繁的网络请求、数据库读写、用户交互——正是异步非阻塞最拿手的领域。理解这一模型，才能真正理解 JavaScript 为什么能承载从微博到电商、从在线文档到协同编辑等海量用户的交互式应用。