async函数语法统一但执行行为因环境而异：浏览器中微任务紧随宏任务立即执行以保障UI响应；Node.js中受libuv阶段调度影响，process.nextTick优先级高于Promise；Electron则依主/渲染进程不同分别遵循Node或浏览器模型。
async 函数在 JavaScript 中是统一的语法规范，但它的实际执行行为会因运行环境不同而产生明显差异——不是语法变了，而是底层事件循环、调度机制和可用 API 不同导致的。
浏览器中：UI 优先，微任务紧随宏任务之后
浏览器的 Event Loop 每执行完一个宏任务（如点击事件、setTimeout 回调），就立即清空全部微任务队列（Promise.then、await 后续代码）。这种设计保障了 UI 渲染的及时性，也使得 async/await 的响应看起来更“顺滑”。例如：
- await fetch() 后的代码会被放入微任务队列，在当前 JS 执行栈清空后立刻执行，不等下一帧渲染
- 频繁的 await 链不会阻塞页面交互，但若逻辑过重，仍可能影响帧率
- 受限于同源策略、CSP 和沙箱机制，async 操作无法绕过安全限制（比如读本地文件）
Node.js 中：阶段化调度，process.nextTick 有更高优先级
Node.js 的事件循环由 libuv 管理，分为 timers、poll、check 等六个固定阶段。微任务（包括 await 后续）并非在每个宏任务后都立刻执行，而是在阶段切换前集中处理——尤其在 poll 阶段结束后。
- await 后的代码属于微任务，但执行时机受所处阶段影响；比如 I/O 回调后才批量处理微任务
- process.nextTick() 的回调优先级高于 Promise.then，甚至能在当前操作结束前就插入执行
- setImmediate() 属于 check 阶段，在 poll 阶段之后执行，常比 setTimeout(0) 更晚触发
Electron 中：双进程模型带来执行路径分化
Electron 应用里，async 函数的行为取决于它运行在主进程还是渲染进程：
立即学习“Java免费学习笔记（深入）”；
- 渲染进程（Chromium）行为与浏览器一致，支持 fetch、DOM 操作，但默认禁用 Node.js API
- 主进程（Node.js）可直接使用 fs、child_process 等模块，async/await 多用于文件读写、服务监听等系统级操作
- 跨进程调用需通过 ipcRenderer/ipcMain，await 等待的是 IPC 响应，而非原生异步操作，延迟和错误处理逻辑完全不同
共性与关键注意事项
无论在哪种环境，async 函数返回 Promise、await 暂停函数执行、错误需 try/catch 捕获这些语义完全一致。真正影响表现的是：
- 底层 I/O 实现：浏览器 fetch 依赖网络栈，Node.js 的 http 模块走 libuv 线程池
- 内存与 GC 行为：长期运行的 Node.js 服务对 Promise 链深度更敏感，易触发频繁垃圾回收
- 并行优化逻辑通用：多个无依赖异步操作务必用 Promise.all，避免串行 await —— 这条在所有环境都适用
