高级 .NET 问答 02：异步并发与 ASP.NET Core 生产边界

结论： ThreadPool 复用工作线程执行短期任务，以降低频繁创建和销毁线程的成本

原因： 常见误区是“每个 Task 都会获得一条新建且专属的操作系统线程”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 长时间阻塞或独占线程的工作会降低复用效率并影响其他任务

最小示例： 当“请求量上升后可用工作线程不足”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 真正的异步 I/O 在等待期间通常不需要占用工作线程，完成后再调度延续

原因： 常见误区是“await 网络请求期间会始终占住当前线程空转”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 具体 API 必须提供异步实现，把同步调用包进 Task.Run 不会变成异步 I/O

最小示例： 当“大量并发网络等待却线程数较稳定”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： TaskCreationOptions.LongRunning 向调度器表达任务可能长期运行，默认调度器可选择专用线程

原因： 常见误区是“给所有任务添加 LongRunning 能自动提升吞吐量”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 它不是通用加速开关，在线程数量不可控时会增加资源成本

最小示例： 当“后台循环挤占普通线程池工作”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： await 默认会根据当前 awaiter 和环境安排延续，库代码可按契约选择 ConfigureAwait

原因： 常见误区是“调用一次 ConfigureAwait(false) 后后续所有代码永不切线程”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： ConfigureAwait(false) 只影响该等待点，不能清除整个调用链的线程需求

最小示例： 当“库方法被 UI 调用时延续位置不一致”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 在需要回到被阻塞上下文的异步调用链上使用 Result 或 Wait 可能形成互相等待

原因： 常见误区是“任何 Task.Result 在所有 .NET 应用中都会必然死锁”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 是否死锁取决于上下文和调用链，但同步阻塞仍会带来线程占用风险

最小示例： 当“UI 线程同步等待异步方法后界面冻结”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： ExecutionContext 携带安全、区域性和 AsyncLocal 等环境数据并随常见异步调度流动

原因： 常见误区是“ExecutionContext 的作用是固定 Task 的线程编号”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 传播的是逻辑执行上下文，不保证延续使用同一物理线程

最小示例： 当“跨线程 await 后仍能读取相关上下文值”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 频繁变化的大量 AsyncLocal 状态会增加 ExecutionContext 捕获与切换成本

原因： 常见误区是“AsyncLocal 只是字典读取，因此在所有场景都零成本”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 性能影响依赖调度频率和状态数量，应通过基准或跟踪确认

最小示例： 当“高频异步管道出现额外调度开销”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： AsyncLocal 保存可变引用对象时，多个逻辑分支可能观察到同一对象的内部修改

原因： 常见误区是“异步分支会自动深复制 AsyncLocal 中的对象图”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 赋新值与修改所引用对象是不同语义，隔离需要不可变快照或显式复制

最小示例： 当“并行子任务相互覆盖上下文字段”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 被等待操作已完成时，异步方法可能沿同步路径继续执行并减少调度

原因： 常见误区是“只要方法返回 Task 就至少发生一次线程切换”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 同步完成不代表方法签名变成同步，也不能假定所有输入都命中该路径

最小示例： 当“缓存命中时异步方法很快完成”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： ValueTask 适合高比例同步完成且分配敏感的底层路径，但消费和组合规则比 Task 更严格

原因： 常见误区是“ValueTask 在所有异步 API 中都比 Task 更快且更安全”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 通常只能等待一次，除非已转换为 Task 或底层来源明确允许重复消费

最小示例： 当“调用方多次 await 同一个结果出现异常”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 有界 Channel 通过容量限制让生产速度超过消费速度时应用明确的等待或丢弃策略

原因： 常见误区是“设置容量后 Channel 会自动把多余消息持久化到磁盘”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 容量应结合单项内存、峰值速率和可接受延迟估算

最小示例： 当“突发流量导致队列长期满载”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： DropNewest、DropOldest 和 DropWrite 会以不同方式牺牲数据，应由业务语义决定能否使用

原因： 常见误区是“任何丢弃模式都能保证每条消息至少处理一次”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 关键命令或资金事件通常不能仅靠内存丢弃队列处理

最小示例： 当“遥测采样允许丢弃部分旧数据”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： EnableBuffering 可让请求体在内存阈值内缓冲并在更大时转储到临时文件，从而支持重新读取

原因： 常见误区是“启用缓冲不会产生任何内存或磁盘成本”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 必须控制请求大小、阈值、磁盘空间并在读取后恢复 Position

最小示例： 当“上传大文件时临时磁盘耗尽”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 流式反序列化可逐步处理数据而不必把完整请求体复制为一个大字符串

原因： 常见误区是“使用 Stream 参数后框架保证整个处理过程零分配”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 对象模型和解析器仍可能保留数据，必须测量峰值内存并处理取消

最小示例： 当“大 JSON 数组导致 LOH 压力”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 响应头在响应开始后通常不能再安全修改，流式端点应在首次写入前完成状态码和头设置

原因： 常见误区是“任何时候都能修改响应头且框架会重写已发送数据”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 代理缓冲和客户端行为会影响首字节可见时间

最小示例： 当“写入部分正文后异常处理中设置状态码失败”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： IAsyncEnumerable 等返回形态可支持逐项序列化，但实际刷新和客户端可见性受格式化器与缓冲策略影响

原因： 常见误区是“返回异步流就保证每个元素立即到达浏览器”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 异常发生在部分响应发送后时无法再返回标准 ProblemDetails

最小示例： 当“客户端长时间看不到服务端已生成数据”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 响应压缩可降低可压缩内容的带宽，但增加 CPU，并受内容类型、HTTPS 风险和客户端协商限制

原因： 常见误区是“开启压缩后任何响应都会更快且体积更小”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 已压缩媒体和小响应未必受益，流式刷新也会受压缩缓冲影响

最小示例： 当“CPU 升高但图片大小没有变化”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： RequestHeadersTimeout 限制服务器接收完整请求头可用的时间，有助于降低慢速连接占用

原因： 常见误区是“请求头超时控制整个业务处理的总执行时间”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 取值需要兼顾真实网络条件与慢速攻击风险

最小示例： 当“慢速发送请求头长期占用连接”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： HTTP/2 每连接并发流上限可限制单连接占用，但总容量还取决于连接数和应用并发

原因： 常见误区是“设置 MaxStreamsPerConnection 就完成全站用户配额控制”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 拒绝额外流不等于业务级限流，也不保护所有下游资源

最小示例： 当“少量连接发起大量并发请求”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： Forwarded Headers 中间件只应信任已配置的代理或网络，避免客户端伪造来源信息

原因： 常见误区是“只要存在 X-Forwarded-For 就应无条件作为真实客户端 IP”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 代理拓扑变化后必须同步更新 KnownProxies、KnownNetworks 与转发限制

最小示例： 当“攻击者伪造来源绕过 IP 策略”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。