async/await 不降低接口耗时，但提升错误可控性与执行稳定性：需显式try/catch捕获异常、合理使用Promise.allSettled和并发控制、避免高频场景滥用、脚本加载阶段需区分async/defer用途。
async/await 本身不提升接口耗时，但能显著改善错误可控性和执行节奏——关键不在“等得快”，而在“错得明、控得准、跑得稳”。
异常必须显式捕获，不能依赖静默失败
await 抛出的错误不会向上穿透调用栈，未捕获就会变成 unhandled rejection，既难调试又可能拖慢微任务队列。
- 每个 await 都应包裹在 try/catch 中，尤其涉及网络、解析、转换等易错环节
- 避免只在最外层加一次 try/catch：深层 await 出错后，后续逻辑仍会执行，造成状态不一致
- 对多个并行请求，用 Promise.allSettled() 替代 Promise.all()，防止一个失败导致整组中断
并发控制比单纯“加 await”更重要
连续 await 是串行等待，而真实场景中多数请求彼此独立。盲目串行不仅慢，还放大单点故障影响。
- 无依赖的请求（如获取用户信息 + 获取配置项）应统一 Promise.all() 并发发起
- 有依赖的链路（如先登录再拉取权限）才用 await 逐级等待，且建议拆成明确步骤函数，便于单独测试和重试
- 高并发场景下，可用 p-limit 等工具限制同时进行的请求数量，避免触发服务端限流或浏览器连接数上限
避免高频 async 函数带来的状态机开销
async 函数底层是状态机，每次调用都会创建上下文、记录 state、管理 builder。对毫秒级高频操作（如滚动监听中的计算），它反而比原生 Promise 更重。
立即学习“Java免费学习笔记（深入）”；
- 每秒执行几十次以上的逻辑，优先考虑普通函数 + Promise.resolve()，而非 async/await
- 不要为单个简单 Promise 包一层 async —— 比如 const getValue = async () => localStorage.getItem('x') 就属于冗余封装
- 真正需要暂停恢复语义的，才是 async 的合理使用场景：比如多步表单提交、带校验的文件上传流程
加载阶段就该介入，不止于运行时
很多异常和性能问题其实在脚本还没执行前就已注定——比如 async 脚本里直接访问 DOM，或 defer 脚本因顺序错乱引发 undefined 错误。
- 标记为 async 的脚本，禁止访问 document.body 等尚未解析完成的节点；需操作 DOM 时，改用 addEventListener('DOMContentLoaded', ...)
- 业务主逻辑脚本用 defer，确保按 HTML 中声明顺序执行，避免 library.js 还没加载完，app.js 就开始调用 $
- 第三方统计、监控类脚本用 async，它们不依赖页面结构，也不影响核心功能，早执行晚执行都可接受
