异步编程中变量作用域由闭包决定，异常上下文需手动传递，上下文隔离依赖显式机制；三者共同影响执行流、错误追踪与数据归属。
异步函数中的变量作用域和异常上下文，不是简单的“函数里能用什么变量”或“错误发生在哪里”的问题，而是涉及执行流切换、闭包捕获、上下文隔离三个关键层面。理解清楚，才能避免变量意外共享、错误定位失焦、日志链路断裂等典型问题。
变量作用域：闭包决定可见性，而非调用时机
在 async/await 或 Promise 链中，变量是否可访问，取决于它**定义时所处的词法作用域**，而不是它被读取时的执行位置。一个常见误区是认为“await 后面的代码属于新上下文”，其实不然——只要变量在当前函数体内声明（var/let/const），它就在该函数的闭包中被保留。
- let/const 声明的变量只在其块级作用域内有效，即使在 await 后使用，也仍受该块约束；跨块访问会报 ReferenceError
- 函数参数和外层闭包变量会被完整捕获，例如 async function handle(req) { const id = req.id; await db.find(id); console.log(id); } —— id 在 await 前后都可用，且值不会因其他请求干扰
- 避免在循环中直接用 var 声明异步回调变量，比如 for (var i = 0; i console.log(i), 0); } 输出全是 3；应改用 let 或立即闭包
异常上下文：堆栈不中断，但执行流已切换
async 函数抛出异常时，JavaScript 会保留原始调用路径的堆栈信息（如从 route → service → db 的链条），但实际执行上下文已经切换到微任务队列。这意味着：
- try/catch 只能捕获同函数内 await 后的同步错误，无法自动捕获深层异步调用中未被处理的 Promise rejection
- 未被 catch 的 Promise rejection 会触发 unhandledrejection 事件，此时原始调用栈仍在，但 this、局部变量等运行时上下文已不可访问
- 错误对象本身不携带执行上下文快照，比如用户 ID、requestId 这类业务信息不会自动附着在 Error 实例上，需手动注入
上下文隔离：靠显式传递或专用上下文管理器
Node.js 或 Python asyncio 中，单线程事件循环下多个请求共用同一 JS 引擎或 event loop，全局变量或普通闭包无法天然隔离请求上下文。这时候不能依赖作用域机制，而要借助工具：
- 手动透传是最直接方式：把 requestId、userId 等作为参数逐层传入，适合简单链路，但易遗漏、破坏函数纯洁性
- Acontext 类库（如 memodb-io/Acontext）提供异步安全的上下文容器：在中间件入口 set({ userId, traceId })，后续任意深度的 await 调用中都能 get() 获取，底层利用 AsyncLocalStorage（Node.js）或 contextvars（Python）实现任务局部存储
- 日志与追踪系统需主动绑定上下文：例如 winston 的 child logger、OpenTelemetry 的 currentSpan，必须在请求开始时初始化，并在每个异步步骤中显式延续
本质上，异步编程放大了作用域和上下文的差异：作用域解决“谁能看见这个变量”，上下文解决“这个变量此刻属于谁”。写异步代码时，既要写对 let 和 const，也要想清数据归属和错误归因路径。
