async/await 语法让异步代码呈现出同步化的书写风格，但许多开发者仅停留在表层认知。其真正的价值在于推动代码结构迈向更加清晰与可控——尤其是在构建前端防腐拦截层这类对局部性要求极高的业务逻辑时，优势更为明显。

那么，async/await 本身能否直接实现“高局部性”或“防腐拦截层”？答案显然是否定的。但它提供了一种最为自然且可控的执行模型，关键不在于语法糖本身，而在于借助它来引导结构设计的方法。

什么是高局部性的防腐拦截层原语

简而言之，它指的是一个职责单一、边界清晰、副作用收敛的异步业务单元。例如以下典型场景：

• 统一鉴权检查：读取 token → 验证有效期 → 刷新或跳转
• 请求前参数标准化：自动补全 tenantId、序列化 body、添加 traceId
• 响应后错误归一化：将 401/403/500 等状态码映射为可识别的业务错误码
• 离线兜底策略：网络失败时读取缓存，同时标记 stale 状态

这些逻辑必须满足若干硬性条件：仅依赖明确输入、不污染外部状态、可独立测试、失败时不影响主流程（要么优雅降级，要么明确中断）。

用 async/await 实现局部性保障的核心写法

关键并非简单地给函数加上 async/await 关键字，而是通过函数契约来明确行为边界：

• 每个拦截原语均定义为独立的 async 函数，只接收原始上下文（例如 requestConfig、response、error），返回处理后的版本或抛出拦截错误。
• 函数体内禁止直接操作全局 store、修改入参对象、调用未声明的依赖副作用函数。
• 所有异步依赖都显式传入（如 authClient、cacheAdapter），便于 mock 和替换。
• 使用 try/catch 包裹 await 表达式，将异步失败转化为可预测的错误类型（例如 AuthError、NetworkStaleError）。

这样一来，每个原语就像一个小黑盒：输入输出明确，内部逻辑完全封闭。这正是高局部性落地的核心实践。

组合多个原语而不破坏局部性

避免链式 await 堆叠导致责任扩散，推荐采用“管道式组合”：

• 编写一个轻量 composeInterceptors 工具函数，接收多个 async 原语，按顺序执行并透传上下文。
• 每个原语只关心自己的输入和输出，完全不会感知前后环节；失败时由上层统一捕获并降级。
• 示例：const processed = await composeInterceptors([authCheck, addTrace, validateBody])(rawReq)

这种模式的优势在于：新增或调整拦截逻辑时，仅需修改管道数组，完全无需改动每个原语的内部代码。

与 Promise 链的本质区别

很多开发者习惯了 Promise.then() 链式调用，但它存在一个隐患：容易隐式共享闭包变量，且难以隔离错误域。而 async/await 强制你将每一步拆解为命名函数，天然支持：

• 单步调试：可以在任意 await 行设置断点，查看当前上下文快照
• 单测覆盖：每个原语可单独 await 测试，无需模拟整个链路
• 条件跳过：用 if/else 控制是否执行某个拦截器，逻辑清晰且不嵌套

这才是高局部性落地的技术支点——并非语法本身有多强大，而是它让“小函数 + 明确契约 + 同步感书写”成为默认习惯。