JavaScript异步编程核心要点

JavaScript异步编程绝非锦上添花的技巧，而是由其单线程事件循环本质决定的生存法则——无论在浏览器中调用fetch、还是在Node.js里读取文件，任何同步阻塞操作都会让整个应用瞬间卡死；理解何时必须用Promise/await、为何fs.readFileSync会扼杀并发性能、如何避免“假异步”陷阱（如忘记返回Promise或误将并行写成串行），才是真正驾驭JS运行时的关键。掌握它，你写的不是代码，而是可伸缩、高响应、不掉帧的真实应用。

JavaScript 中异步编程不是“可选项”，而是运行环境决定的刚性需求：浏览器和 Node.js 都基于单线程事件循环，任何阻塞操作（如网络请求、文件读取、定时器）若用同步方式实现，整个程序会卡死。

为什么 fetch 默认不阻塞主线程

因为浏览器禁止同步网络请求（除已废弃的 XMLHttpRequest.open(..., false)），fetch 从设计上就是 Promise-based。试图用 await 在非 async 函数里调用？会直接报 SyntaxError: await is only valid in async functions。

• fetch 返回 Promise，必须用 .then() 或 await 消费，没有“同步等结果”的合法路径
• 即使加了 await，也只是暂停当前 async 函数执行，不冻结事件循环——其他任务（如用户点击、动画帧）照常处理
• 想强行同步？唯一办法是退回到 Web Workers + Atomics.wait，但浏览器不支持，Node.js 也仅限 Worker 线程内部，且极度受限

Node.js 里 fs.readFile 和 fs.readFileSync 的真实代价

fs.readFileSync 看似方便，但在生产服务中等于主动放弃吞吐量。它会让当前线程（Node.js 只有一个 JS 主线程）停在系统调用上，无法响应新请求。

• 100 个并发请求，全用 readFileSync → 最多同时处理 1 个，其余 99 个排队等待磁盘 I/O 完成
• 改用 fs.readFile + Promise.all → 所有 I/O 并发发起，内核自行调度，JS 线程持续轮询完成事件
• 注意：fs.promises.readFile 是推荐写法，避免回调地狱；util.promisify(fs.readFile) 是兼容旧版的备选

常见错误：把异步逻辑当成同步流程写

典型表现是函数返回 undefined，或状态未更新就执行下一步——本质是忘了异步操作不会“立即”产出值。

• 错误模式：function getData() { fetch('/api').then(res => res.json()); } → 这个函数永远返回 undefined
• 正确做法：要么返回 Promise（return fetch(...).then(...)），要么标记为 async 并用 return await
• 更隐蔽的坑：for (const id of ids) { await db.query(id); } 是串行，想并行得用 Promise.all(ids.map(id => db.query(id)))

真正难的不是写 async/await，而是判断哪些操作天然异步（I/O、计时器、事件监听）、哪些看似异步实则同步（如 Array.prototype.map）、以及何时该串行何时该并行——这些不靠语法，靠对运行时模型的理解。

到这里，我们也就讲完了《JavaScript异步编程核心要点》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！