.NET 异步并发试题 03：ExecutionContext、AsyncLocal 与上下文传播
041 关于ExecutionContext，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. ExecutionContext 的作用是固定 Task 的线程编号
- B. ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动
- C. 传播的是逻辑执行上下文，不保证延续使用同一物理线程
- D. 只要观察到“跨线程 await 后仍能读取相关上下文值”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了ExecutionContext可直接依赖的规则：“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”。“传播的是逻辑执行上下文，不保证延续使用同一物理线程”是应用规则前必须确认的边界，不是规则本身；“ExecutionContext 的作用是固定 Task 的线程编号”则把常见现象或实现细节扩大成了平台保证。场景“跨线程 await 后仍能读取相关上下文值”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
042 生产环境出现“跨线程 await 后仍能读取相关上下文值”时，针对ExecutionContext应如何排查？
难度： 进阶
- A. 先验证“传播的是逻辑执行上下文，不保证延续使用同一物理线程”，再使用运行时指标、日志或最小复现检查“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”是否成立。
- B. 直接采用“ExecutionContext 的作用是固定 Task 的线程编号”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“传播的是逻辑执行上下文，不保证延续使用同一物理线程”的验证。
- D. 只检查代码是否能够编译，通过后便认定“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”在当前部署中必然成立。
查看答案与解析
正确答案A
“跨线程 await 后仍能读取相关上下文值”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“传播的是逻辑执行上下文，不保证延续使用同一物理线程”，再以“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”组织证据。采用误区“ExecutionContext 的作用是固定 Task 的线程编号”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
043 评审ExecutionContext相关实现时，以下哪项判断不成立？
难度： 实战
- A. ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动
- B. 传播的是逻辑执行上下文，不保证延续使用同一物理线程
- C. 遇到“跨线程 await 后仍能读取相关上下文值”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. ExecutionContext 的作用是固定 Task 的线程编号
查看答案与解析
正确答案D
题目要求找出不成立的判断，“ExecutionContext 的作用是固定 Task 的线程编号”正是ExecutionContext的典型误区。主规则“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”描述了实现应依赖的契约，边界“传播的是逻辑执行上下文，不保证延续使用同一物理线程”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
044 准备上线涉及ExecutionContext的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“ExecutionContext 的作用是固定 Task 的线程编号”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”修改代码，但不核对“传播的是逻辑执行上下文，不保证延续使用同一物理线程”或目标发布模式。
- C. 依据“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”实现，在“传播的是逻辑执行上下文，不保证延续使用同一物理线程”成立的环境中验证，并为“跨线程 await 后仍能读取相关上下文值”保留可观测证据和回退条件。
- D. 只验证“传播的是逻辑执行上下文，不保证延续使用同一物理线程”，实现仍继续依赖“ExecutionContext 的作用是固定 Task 的线程编号”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动”，部署环境满足“传播的是逻辑执行上下文，不保证延续使用同一物理线程”，并能在“跨线程 await 后仍能读取相关上下文值”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
045 关于AsyncLocal，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. AsyncLocal 值只按操作系统线程隔离且不会跨 await
- B. 它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储
- C. AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎
- D. 只要观察到“并发请求需要各自的关联标识”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了AsyncLocal可直接依赖的规则：“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”。“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”是应用规则前必须确认的边界，不是规则本身；“AsyncLocal 值只按操作系统线程隔离且不会跨 await”则把常见现象或实现细节扩大成了平台保证。场景“并发请求需要各自的关联标识”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
046 生产环境出现“并发请求需要各自的关联标识”时，针对AsyncLocal应如何排查？
难度： 进阶
- A. 直接采用“AsyncLocal 值只按操作系统线程隔离且不会跨 await”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”，再使用运行时指标、日志或最小复现检查“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”的验证。
- D. 只检查代码是否能够编译，通过后便认定“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”在当前部署中必然成立。
查看答案与解析
正确答案B
“并发请求需要各自的关联标识”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”，再以“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”组织证据。采用误区“AsyncLocal 值只按操作系统线程隔离且不会跨 await”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
047 评审AsyncLocal相关实现时，以下哪项判断不成立？
难度： 实战
- A. AsyncLocal 值只按操作系统线程隔离且不会跨 await
- B. AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎
- C. 它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储
- D. 遇到“并发请求需要各自的关联标识”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“AsyncLocal 值只按操作系统线程隔离且不会跨 await”正是AsyncLocal的典型误区。主规则“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”描述了实现应依赖的契约，边界“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
048 准备上线涉及AsyncLocal的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“AsyncLocal 值只按操作系统线程隔离且不会跨 await”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”修改代码，但不核对“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”或目标发布模式。
- C. 只验证“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”，实现仍继续依赖“AsyncLocal 值只按操作系统线程隔离且不会跨 await”这一未经证明的假设。
- D. 依据“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”实现，在“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”成立的环境中验证，并为“并发请求需要各自的关联标识”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“AsyncLocal 为异步控制流提供环境数据，子流程可继承值但修改通知与引用对象仍需谨慎”，部署环境满足“它适合请求相关上下文，不适合作为任意业务参数的隐式全局存储”，并能在“并发请求需要各自的关联标识”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
049 关于上下文捕获成本，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. AsyncLocal 只是字典读取，因此在所有场景都零成本
- B. 性能影响依赖调度频率和状态数量，应通过基准或跟踪确认
- C. 只要观察到“高频异步管道出现额外调度开销”，就能把这次现象视为所有环境中的固定行为。
- D. 频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本
查看答案与解析
正确答案D
正确项给出了上下文捕获成本可直接依赖的规则：“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”。“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”是应用规则前必须确认的边界，不是规则本身；“AsyncLocal 只是字典读取，因此在所有场景都零成本”则把常见现象或实现细节扩大成了平台保证。场景“高频异步管道出现额外调度开销”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
050 生产环境出现“高频异步管道出现额外调度开销”时，针对上下文捕获成本应如何排查？
难度： 进阶
- A. 直接采用“AsyncLocal 只是字典读取，因此在所有场景都零成本”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”，再使用运行时指标、日志或最小复现检查“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”的验证。
- D. 只检查代码是否能够编译，通过后便认定“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”在当前部署中必然成立。
查看答案与解析
正确答案B
“高频异步管道出现额外调度开销”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”，再以“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”组织证据。采用误区“AsyncLocal 只是字典读取，因此在所有场景都零成本”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
051 评审上下文捕获成本相关实现时，以下哪项判断不成立？
难度： 实战
- A. 频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本
- B. 性能影响依赖调度频率和状态数量，应通过基准或跟踪确认
- C. AsyncLocal 只是字典读取，因此在所有场景都零成本
- D. 遇到“高频异步管道出现额外调度开销”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“AsyncLocal 只是字典读取，因此在所有场景都零成本”正是上下文捕获成本的典型误区。主规则“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”描述了实现应依赖的契约，边界“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
052 准备上线涉及上下文捕获成本的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”实现，在“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”成立的环境中验证，并为“高频异步管道出现额外调度开销”保留可观测证据和回退条件。
- B. 依据“AsyncLocal 只是字典读取，因此在所有场景都零成本”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”修改代码，但不核对“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”或目标发布模式。
- D. 只验证“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”，实现仍继续依赖“AsyncLocal 只是字典读取，因此在所有场景都零成本”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本”，部署环境满足“性能影响依赖调度频率和状态数量，应通过基准或跟踪确认”，并能在“高频异步管道出现额外调度开销”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
053 关于SuppressFlow，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复
- B. SuppressFlow 只关闭日志输出，不影响上下文数据
- C. 滥用会丢失诊断关联、安全或区域性数据
- D. 只要观察到“后台工作不应继承请求身份”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了SuppressFlow可直接依赖的规则：“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”。“滥用会丢失诊断关联、安全或区域性数据”是应用规则前必须确认的边界，不是规则本身；“SuppressFlow 只关闭日志输出，不影响上下文数据”则把常见现象或实现细节扩大成了平台保证。场景“后台工作不应继承请求身份”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
054 生产环境出现“后台工作不应继承请求身份”时，针对SuppressFlow应如何排查？
难度： 进阶
- A. 直接采用“SuppressFlow 只关闭日志输出，不影响上下文数据”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“滥用会丢失诊断关联、安全或区域性数据”的验证。
- C. 只检查代码是否能够编译，通过后便认定“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”在当前部署中必然成立。
- D. 先验证“滥用会丢失诊断关联、安全或区域性数据”，再使用运行时指标、日志或最小复现检查“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”是否成立。
查看答案与解析
正确答案D
“后台工作不应继承请求身份”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“滥用会丢失诊断关联、安全或区域性数据”，再以“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”组织证据。采用误区“SuppressFlow 只关闭日志输出，不影响上下文数据”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
055 评审SuppressFlow相关实现时，以下哪项判断不成立？
难度： 实战
- A. SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复
- B. SuppressFlow 只关闭日志输出，不影响上下文数据
- C. 滥用会丢失诊断关联、安全或区域性数据
- D. 遇到“后台工作不应继承请求身份”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“SuppressFlow 只关闭日志输出，不影响上下文数据”正是SuppressFlow的典型误区。主规则“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”描述了实现应依赖的契约，边界“滥用会丢失诊断关联、安全或区域性数据”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
056 准备上线涉及SuppressFlow的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“SuppressFlow 只关闭日志输出，不影响上下文数据”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”修改代码，但不核对“滥用会丢失诊断关联、安全或区域性数据”或目标发布模式。
- C. 依据“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”实现，在“滥用会丢失诊断关联、安全或区域性数据”成立的环境中验证，并为“后台工作不应继承请求身份”保留可观测证据和回退条件。
- D. 只验证“滥用会丢失诊断关联、安全或区域性数据”，实现仍继续依赖“SuppressFlow 只关闭日志输出，不影响上下文数据”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“SuppressFlow 可阻止 ExecutionContext 流向后续异步工作，但必须在明确隔离边界内成对恢复”，部署环境满足“滥用会丢失诊断关联、安全或区域性数据”，并能在“后台工作不应继承请求身份”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
057 关于引用值泄漏，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 异步分支会自动深复制 AsyncLocal 中的对象图
- B. AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改
- C. 赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制
- D. 只要观察到“并行子任务相互覆盖上下文字段”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了引用值泄漏可直接依赖的规则：“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”。“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”是应用规则前必须确认的边界，不是规则本身；“异步分支会自动深复制 AsyncLocal 中的对象图”则把常见现象或实现细节扩大成了平台保证。场景“并行子任务相互覆盖上下文字段”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
058 生产环境出现“并行子任务相互覆盖上下文字段”时，针对引用值泄漏应如何排查？
难度： 进阶
- A. 直接采用“异步分支会自动深复制 AsyncLocal 中的对象图”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”的验证。
- C. 只检查代码是否能够编译，通过后便认定“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”在当前部署中必然成立。
- D. 先验证“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”，再使用运行时指标、日志或最小复现检查“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”是否成立。
查看答案与解析
正确答案D
“并行子任务相互覆盖上下文字段”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”，再以“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”组织证据。采用误区“异步分支会自动深复制 AsyncLocal 中的对象图”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
059 评审引用值泄漏相关实现时，以下哪项判断不成立？
难度： 实战
- A. AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改
- B. 赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制
- C. 异步分支会自动深复制 AsyncLocal 中的对象图
- D. 遇到“并行子任务相互覆盖上下文字段”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“异步分支会自动深复制 AsyncLocal 中的对象图”正是引用值泄漏的典型误区。主规则“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”描述了实现应依赖的契约，边界“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
060 准备上线涉及引用值泄漏的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”实现，在“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”成立的环境中验证，并为“并行子任务相互覆盖上下文字段”保留可观测证据和回退条件。
- B. 依据“异步分支会自动深复制 AsyncLocal 中的对象图”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”修改代码，但不核对“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”或目标发布模式。
- D. 只验证“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”，实现仍继续依赖“异步分支会自动深复制 AsyncLocal 中的对象图”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改”，部署环境满足“赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制”，并能在“并行子任务相互覆盖上下文字段”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。