规范团队异步开发需统一认知、约束行为、降低协作成本，从职责边界、错误处理、串行/并行选择、顶层await限制四维度落地。
规范团队异步开发，关键不是堆砌语法，而是统一认知、约束行为、降低协作成本。async/await 本身是 Promise 的语法糖，但团队若只停留在“会写 await”，就容易出现串行滥用、错误静默、上下文丢失等线上隐患。下面从四个实操维度给出可落地的规范建议。
明确 async 函数的职责边界
async 函数应仅用于真正需要等待异步结果的场景，而非“以防万一”加 async。团队需约定：
- 函数名必须体现异步意图，如 fetchUser、saveDraft、validateToken；禁止命名如 getUser（同步语义）却返回 Promise
- 纯同步计算逻辑不得声明为 async，即使内部用了 await（如误将缓存读取包装成 Promise）
- 工具类函数（如格式化日期、深克隆）严禁加 async，避免调用方产生“它可能异步”的误解
强制错误处理机制
await 不捕获错误，未处理的 rejected Promise 会变成未捕获异常，轻则日志缺失，重则中断流程。规范要求：
- 每个 await 表达式必须处于 try/catch 块中，或由上层统一兜底（如 React 中的 error boundary、Express 中的全局 error handler）
- 禁止在顶层作用域或事件回调中裸写 await，例如：❌ window.addEventListener('click', () => await loadData())
- 网络请求类 await 必须附带超时控制和业务级错误映射，不依赖 fetch 默认行为
区分串行与并行，性能敏感处显式声明
多个 await 按顺序执行是默认行为，但多数场景中依赖关系并不严格。团队需建立判断习惯：
- 无依赖的异步操作必须用 Promise.all 并行发起，如同时拉取用户信息和权限配置
- 允许失败的并行任务用 Promise.allSettled，避免单点失败阻断整体流程
- 串行链路必须有注释说明依赖原因，例如：// 必须先登录才能获取 profile，故 await 顺序不可调换
限制顶层 await 和模块级副作用
顶层 await（ES2022）虽可用，但在团队工程中易引发模块加载阻塞、SSR 渲染卡顿、测试 mock 困难等问题。规范应：
- 禁用模块顶层 await，所有异步初始化逻辑收口到明确的 init() 函数中
- 组件或服务模块导出的必须是普通函数或类，不导出 async 函数作为“构造入口”
- 构建工具（如 Vite/Webpack）配置中关闭自动注入顶层 await 支持，防止无意引入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
