JavaScript异步编程是单线程事件循环环境下的刚性需求；fetch默认不阻塞主线程因浏览器禁用同步网络请求，且必须用.then()或await消费Promise；fs.readFileSync会阻塞Node.js主线程，降低并发吞吐量，应改用fs.promises.readFile等异步方案。
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，或状态未更新就执行下一步——本质是忘了异步操作不会“立即”产出值。
php中级教程之ajax技术
下载
AJAX即“Asynchronous Javascript And XML”（异步JavaScript和XML），是指一种创建交互式网页应用的网页开发技术。它不是新的编程语言，而是一种使用现有标准的新方法，最大的优点是在不重新加载整个页面的情况下，可以与服务器交换数据并更新部分网页内容，不需要任何浏览器插件，但需要用户允许JavaScript在浏览器上执行。《php中级教程之ajax技术》带你快速
立即学习“Java免费学习笔记（深入）”；
- 错误模式：
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）、以及何时该串行何时该并行——这些不靠语法，靠对运行时模型的理解。
