异步方法中跨await使用的局部变量会被编译器提升为状态机字段，值类型完整复制、引用类型仅存引用，生命周期延长至整个异步操作完成。
异步方法中局部变量被提升为状态机字段
当你在 async 方法里声明一个局部变量（比如 int count = 42; 或 var service = new MyService();），并且这个变量在 await 表达式之后仍被使用，C# 编译器会自动将它“提升”（lift）到由编译器生成的状态机结构体中，作为实例字段保存。这不是闭包捕获，而是编译器对异步状态机的必要改造。
这意味着：变量生命周期脱离了原始栈帧，延长到整个异步操作完成；其值在每次 await 暂停和恢复之间保持不变。
- 仅当变量在
await前后都被引用时才会被提升——如果只在await前使用，它仍留在栈上，不会进入状态机 - 引用类型变量（如
string、自定义类实例）只是引用被保存，对象本身仍在堆上，不受影响 - 值类型（如
int、DateTime、结构体）会被完整复制进状态机字段，不涉及装箱
查看编译器生成的状态机代码（.NET 6+）
用 dotnet build /p:DebugType=embedded 构建后，用 ildasm 或反编译工具（如 ILSpy）打开 DLL，搜索 <MethodName>Async 对应的 <>c__async0 或类似命名的嵌套结构体，就能看到被提升的字段，例如：
private int <count>5__1; private MyService <service>5__2;
这些字段名带数字后缀（如 5__1）是编译器为避免命名冲突生成的；字段名中的数字与变量在方法中的声明顺序和作用域嵌套深度有关。
注意：/p:DebugType=embedded 不影响运行行为，只让调试符号内嵌，方便反编译时保留更多原始结构线索。
常见误解：这不是 Lambda 闭包
很多人误以为这是“闭包捕获”，但二者机制完全不同：
- Lambda 捕获发生在委托创建时，依赖于外围作用域的局部变量容器（通常是编译器生成的类）
- 异步状态机是每个
async方法独有的一次性结构体，字段由编译器静态决定，不涉及委托或Func<>/Action - 没有
DisplayClass类参与——你不会在 IL 中看到类似<>c__DisplayClass1_0的类型 - 即使方法里没写任何 lambda，只要用了
await且有跨 await 引用的局部变量，状态机字段就存在
性能与调试注意事项
状态机字段带来轻微内存开销（每个变量占对应大小，结构体本身通常分配在堆上，除非被优化为栈分配），但更重要的是调试时容易困惑：
- 在调试器中，“局部变量”窗口显示的其实是状态机字段的当前值，不是原始栈变量（因为原始栈帧早已返回）
- 若变量是结构体且较大（如含数组或大量字段），提升后会增加状态机体积，可能影响缓存局部性
-
async void方法的状态机无法被外部观察或等待，错误会直接抛给同步上下文，此时被提升的变量更难追踪
真正容易被忽略的点是：**变量是否被提升，完全取决于控制流路径，而不是声明位置**。比如 if 分支中声明的变量，只有在该分支同时包含 await 和后续使用时，才可能被提升——编译器按实际可达路径分析，不是简单扫描语法树。
