async函数中异步安全的核心是理解控制流、资源生命周期和错误传播，而非简单加await；需显式await关键Promise、合理并发、严谨错误处理、管理共享状态与资源释放，并避免隐式并行。
在 async 函数中编写异步安全的代码，核心是避免隐式竞态、意外的并行执行、未处理的 Promise 拒绝，以及错误地假设执行顺序。关键不是“加 await”，而是理解控制流、资源生命周期和错误传播机制。
明确 await 的作用域和时机
await 只暂停当前 async 函数的执行，不影响其他任务；它不锁线程，也不阻塞事件循环。滥用 await（比如在不该等的地方等）会拖慢吞吐，而漏掉 await 则可能让 Promise “飞走”，导致逻辑错乱或资源泄漏。
- 对所有真正需要结果的 Promise 显式 await，尤其涉及状态变更、I/O 或依赖前序结果时
- 避免在循环中无差别 await —— 如需并发请求，用 Promise.all() 或 Promise.allSettled() 批量处理
- 不要仅因“看起来要等”就加 await：例如 logger.info('start') 后接 await doWork() 是合理；但 await console.log('done') 没有意义（console.log 不返回 Promise）
正确处理错误与拒绝
async 函数内部抛出异常或 Promise 被 reject，都会让函数返回一个被拒绝的 Promise。如果调用方没用 try/catch 或 .catch() 处理，就会触发 unhandledrejection，可能静默失败。
- 在顶层 async 函数（如 API 路由、CLI 主流程）中用 try/catch 包裹整个逻辑块
- 对可能失败的独立操作（如发通知、写日志），用 .catch(() => {}) 或 await promise.catch(() => {}) 隔离影响，避免连锁失败
- 避免空 catch：至少记录错误，或转换为业务可识别的状态（如返回 { success: false, error: 'timeout' }）
管理共享状态与资源生命周期
多个 async 函数可能并发访问同一变量、文件句柄、数据库连接或缓存项。异步安全不等于线程安全，但竞态仍会发生——比如两个请求同时读-改-写计数器，最终只 +1 而非 +2。
- 优先使用不可变数据：更新状态时创建新对象/数组，而非修改原值
- 对必须修改的共享状态，用细粒度锁（如基于 Promise 的简单互斥锁）或原子操作（如 Redis 的 INCR、数据库的 UPDATE ... RETURNING）
- 确保资源释放：文件流、数据库连接、定时器等，在 async 流程结束（无论成功或失败）后显式 cleanup，可用 finally 块或包装成自动释放的类
避免隐式并行与意外交互
看似顺序的代码，可能因缺少 await 变成并行执行；看似独立的操作，可能因共享副作用（如全局变量、单例实例）相互干扰。
- 检查所有 Promise 实例是否都被 await 或明确传递给 Promise 组合方法——未 await 的 Promise 是“脱管”的
- 警惕构造函数或模块初始化中的异步副作用（如 new CacheManager() 内部启动预热 fetch），它们可能在 import 时就触发，且难以追踪
- 测试并发场景：用 Promise.all([fn(), fn(), fn()]) 模拟多请求，观察状态、日志、数据库记录是否符合预期
