高级 .NET 问答 04：诊断工具、现代工程与安全

结论： 可靠微基准需要预热以减少首次 JIT、缓存填充和一次性初始化对稳态结果的污染

原因： 常见误区是“预热会让基准伪造性能，因此任何测试都不应预热”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 若目标就是冷启动则应单独设计冷启动实验而不是套用稳态预热

最小示例： 当“首次迭代远慢于后续迭代”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 基准必须消费计算结果并避免编译器删除无可观察效果的工作

原因： 常见误区是“Release 模式会保证所有写出的代码都实际执行”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 消费结果不能改变被测算法的核心成本或引入主导开销

最小示例： 当“空循环基准显示异常快”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： MemoryDiagnoser 可报告托管分配和 GC 信息，帮助区分耗时与内存成本

原因： 常见误区是“Allocated 为零即可证明实现没有任何资源成本”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 报告的分配不包含所有本机资源和进程外成本

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

结论： 高分配率会增加 GC 工作量，即使托管堆当前大小没有持续增长也可能影响吞吐

原因： 常见误区是“堆大小稳定即可排除分配导致的性能问题”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 短时间采样需结合请求量归一化，不能只比较绝对字节数

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

结论： 异常计数可发现被捕获后未进入错误日志的高频异常路径

原因： 常见误区是“接口返回成功就代表进程内部没有异常发生”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 计数不区分业务严重程度，仍需 trace 或日志定位类型和栈

最小示例： 当“吞吐下降但错误率面板正常”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： EventPipe 提供跨平台运行时事件管道，可由 dotnet-trace 等工具采集事件和采样数据

原因： 常见误区是“EventPipe 只在 Windows 上依赖 ETW 才能工作”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 启用提供程序与级别会影响数据量和开销，应控制采集窗口

最小示例： 当“Linux 容器中采集运行时跟踪”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 选择正确 Provider、关键字和级别才能采集目标运行时或应用事件

原因： 常见误区是“默认采集会自动包含所有框架和业务事件的最大细节”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 全量高详细度长时间采集可能产生显著文件和运行开销

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

结论： nettrace 可转换或由 PerfView、SpeedScope 等工具分析，格式转换不会增加原始未采集信息

原因： 常见误区是“把 trace 转为另一格式能恢复未启用的事件”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 跨工具展示的聚合方式可能不同，应保留原始文件和采集配置

最小示例： 当“不同分析器显示比例不完全一致”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 增量生成器把输入转换拆为可缓存步骤，使未变化输入避免重复计算

原因： 常见误区是“使用 IIncrementalGenerator 就保证每次构建完全不执行任何旧步骤”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 缓存依赖值相等性和流水线设计，捕获全局可变状态会破坏可预测性

最小示例： 当“小改动导致生成器全量重算”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 相同输入应产生稳定源码、提示名和诊断，避免时间戳与随机顺序导致无谓重编译

原因： 常见误区是“生成器直接读取任意网络资源也能保持可重复构建”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 读取外部文件应通过 AdditionalFiles 等声明输入纳入构建依赖

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

结论： 分析器应设计为无共享可变状态并可启用并发执行，以适应编译器并行调用

原因： 常见误区是“编译器保证同一分析器实例永远只在一条线程调用”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 注册动作中的缓存必须不可变或正确同步

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

结论： 诊断应定位到最小且可理解的语法或符号位置，并提供稳定 ID、类别和严重性

原因： 常见误区是“只在文件开头报告所有问题最容易维护且体验相同”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 跨文件问题可使用附加位置，但主位置仍应帮助开发者行动

最小示例： 当“IDE 无法判断具体违规表达式”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 公开分析器规则的 ID 和默认严重性会成为团队配置契约，变更需要兼容与发布说明

原因： 常见误区是“分析器升级可以随意复用旧 ID 表示完全不同的规则”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 提高严重性可能让使用者 CI 突然失败，应提供迁移路径

最小示例： 当“依赖更新后构建出现新错误”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： TargetFrameworks 可为不同目标分别编译，并用条件代码或条件引用表达能力差异

原因： 常见误区是“多目标只会复制同一二进制而不会重新编译”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 公共 API 应尽量保持一致，不能让同一包版本在目标间产生意外语义差异

最小示例： 当“netstandard 与 net10 需要不同实现”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 包的依赖会影响消费者解析图，应避免不必要公开依赖并控制版本范围

原因： 常见误区是“把依赖标记 PrivateAssets=all 后代码可在运行时完全不需要它”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： PrivateAssets 等元数据只改变资产传播，不会消除运行时真实依赖

最小示例： 当“消费者出现依赖版本冲突”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 公共异步 API 通常把 CancellationToken 作为最后一个参数并向下游传播

原因： 常见误区是“接受 CancellationToken 后无需传给数据库和网络调用”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 取消表示调用方不再需要结果，不等同失败或事务自动回滚

最小示例： 当“请求取消但下游仍持续占用资源”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源

原因： 常见误区是“拿到 access token 就能证明用户身份和登录时间”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 它本身不规定用户身份登录声明，应结合 OIDC 等身份协议

最小示例： 当“API 把授权令牌直接当登录会话”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限

原因： 常见误区是“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 部署上可由同一产品承担，但信任职责仍需区分

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

结论： OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存

原因： 常见误区是“任何用户提交的 authority 都可安全用于动态发现”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址

最小示例： 当“攻击者诱导服务加载恶意元数据”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： PKCE 用 code_challenge 和 code_verifier 把授权请求与令牌兑换绑定，降低授权码截获风险

原因： 常见误区是“PKCE 用来加密 access token 的正文内容”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 验证器仍需安全保存在发起流程的客户端上下文中，并使用推荐挑战方法

最小示例： 当“公共客户端无法安全保存 client secret”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。