javascript异步函数非阻塞靠事件循环调度而非多线程：同步代码入栈执行，异步操作交由web api处理，主线程不等待；微任务（如promise.then）在同步任务后立即执行，宏任务（如settimeout）延至下一轮循环。
是的，异步函数在 JavaScript 中确实是非阻塞的——但这个“非阻塞”不是靠多线程实现的，而是由事件循环（Event Loop）配合调用栈、微任务队列和宏任务队列协同调度完成的。关键不在于“函数本身不占时间”，而在于它把耗时操作移交给了浏览器或 Node.js 的 Web API（如 fetch、setTimeout、DOM 事件等），主线程立刻继续执行后续同步代码。
调用栈只跑同步代码，异步逻辑根本不上栈
JavaScript 的调用栈（Call Stack）是严格同步、后进先出的。所有 同步代码 都会立即压栈执行；而 异步函数调用本身（比如 fetch()、setTimeout()、asyncFunction()）只是发起请求、注册回调，然后马上返回，不会让调用栈等待。
-
fetch('/api')立即返回一个 Promise 对象，调用栈立刻清空该行，不等响应回来 -
setTimeout(() => console.log('done'), 1000)把回调交给定时器系统，JS 主线程不暂停 - 哪怕写
await asyncFunction()，也只是让当前 async 函数内部暂停，外部同步代码不受影响
真正的“非阻塞”靠的是任务分类与分时调度
事件循环不按“谁先写谁先跑”，而是按任务类型分优先级执行：
- 同步任务：直接进调用栈，全部执行完才看队列
-
微任务（Microtask）：如
Promise.then、queueMicrotask、async/await后续逻辑，会在每个宏任务结束后立即清空 -
宏任务（Macrotask）：如
setTimeout、setInterval、I/O 回调、UI 渲染，每次只取一个执行
例如这段代码：
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
输出一定是 1 → 4 → 3 → 2，因为 Promise.then 是微任务，在同步代码（1 和 4）执行完后立刻执行；而 setTimeout 是宏任务，要等整个本轮循环结束再进下一轮。
async/await 不等于“阻塞”，只是语法糖下的微任务链
async 函数本身返回 Promise，await 只是暂停当前函数执行，并把后续代码包装成微任务。它不会冻结主线程，也不阻止其他同步或异步逻辑运行。
- 没加
await：直接调用myAsyncFn()就像调用普通函数一样，立刻返回 Promise，不卡主线程 - 加了
await：只暂停该async函数内部的后续语句，外部代码照常执行 - 多个
await是串行微任务，但它们之间仍可被其他微任务（如另一个 Promise.then）插入
所谓“阻塞感”，往往来自误用而非机制本身
开发者觉得“异步变阻塞”，通常是因为：
- 在顶层同步逻辑里写了
await，导致后续同步代码必须等它（这是设计使然，不是 bug） - 把 CPU 密集型操作（如大数组排序、递归计算）错误当成异步处理，其实它仍在主线程跑满栈
- 没区分“发起异步”和“等待结果”——调用是瞬时的，等待是后续的，二者不能混为一谈
真正需要长时间计算时，应使用 Web Worker 搬离主线程，而不是指望 async 解决 CPU 阻塞问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
