JavaScript事件循环本身是单线程非阻塞机制，高并发依赖非阻塞I/O、任务分级调度、Worker线程分担CPU及流式处理背压控制四大策略协同实现。
JavaScript 事件循环本身不是为“支持高并发”而设计的多线程调度器，它本质上是单线程、非阻塞的协调机制。真正让它能应对高并发的，是一整套配合事件循环工作的运行时策略和编程实践——核心在于“不卡住主线程”，把等待时间让出去，让有限的线程资源持续周转。
靠非阻塞 I/O 卸载等待压力
Node.js 和浏览器都把耗时的 I/O 操作（如网络请求、文件读写、数据库查询）交给底层系统或线程池处理，JavaScript 主线程只负责发起请求和注册回调。操作实际在后台完成，主线程立刻返回继续执行其他任务。成千个并发请求不会创建千个线程，而是共享一个事件循环，靠回调排队响应。
- 用
fs.readFile替代fs.readFileSync - HTTP 请求统一走
fetch或axios等异步接口 - 数据库驱动选择支持连接池和异步协议的（如 pg、mysql2）
靠任务分级调度避免饥饿
事件循环区分宏任务（setTimeout、I/O 回调）和微任务（Promise.then、queueMicrotask），微任务总在当前宏任务结束后、下一轮渲染或下一个宏任务前清空。这种优先级设计确保关键逻辑（比如状态更新、错误捕获）及时响应，防止低优先级任务长期霸占控制权。
- 高频 UI 更新用
requestAnimationFrame对齐渲染帧 - 链式异步逻辑尽量用
async/await，避免深层嵌套导致调度延迟 - 避免在 Promise 回调里塞大量同步计算，否则会拖慢微任务队列
靠 Worker 线程分担 CPU 压力
事件循环再高效，也解决不了 CPU 密集型任务的阻塞问题。这时必须把计算型工作移出主线程：浏览器用 Web Workers，Node.js 用 Worker Threads。它们拥有独立的 JavaScript 执行环境和内存空间，通过消息传递与主线程通信，彻底隔离耗时运算。
立即学习“Java免费学习笔记（深入）”；
- 图像压缩、加密解密、大数据排序等适合丢进 Worker
- 主线程只负责派发任务和接收结果，不参与计算过程
- 注意序列化开销，避免频繁传大对象，可使用 Transferable 对象优化
靠流式处理和背压控制管理数据洪流
面对大量数据（如上传大文件、实时日志、消息队列消费），一次性加载到内存会引发 OOM 或 GC 停顿。Stream API 提供分块读写能力，配合 pipe 或 readable.read() 控制数据流动节奏，让事件循环始终有余力处理其他任务。
- 用
fs.createReadStream代替fs.readFileSync处理大文件 - HTTP 响应体用
res.pipe(stream)直接转发，不暂存中间数据 - 消费 Kafka 或 Redis 流时，根据下游处理速度动态调节拉取速率
