高级 .NET 问答 01：CLR、JIT、GC 与 AOT

结论： 托管语言通常先编译为包含 CIL 和元数据的程序集，再由运行时选择后续执行方式

原因： 常见误区是“CIL 就是面向某一 CPU 的最终机器码”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 具体方法能否转换为本机代码还取决于运行时、发布模型与平台

最小示例： 当“同一程序集在不同体系结构上运行”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 类型、成员、签名和特性等元数据支持加载、验证、反射与工具分析

原因： 常见误区是“运行时只能依赖调试符号识别类型”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 元数据存在不代表对应成员可被任意调用或不会被裁剪

最小示例： 当“反射在发布版本中找不到目标成员”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 程序集是版本和部署身份单位，一个程序集可由一个或多个模块组成

原因： 常见误区是“模块与程序集始终是完全相同的对象”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 常见 SDK 项目通常生成单模块程序集，但这不是概念上的唯一形式

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

结论： 分层编译允许方法先以较快生成的代码运行，热点方法随后重新编译为更优化的版本

原因： 常见误区是“分层编译只改变编译器警告级别”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 是否晋升以及时机由运行时和配置决定，不保证每个方法都经历相同步骤

最小示例： 当“服务预热后吞吐逐渐上升”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： JIT 可在满足成本与语义约束时把调用目标内联到调用方以减少调用开销并扩大优化机会

原因： 常见误区是“标记 AggressiveInlining 就能强制任何方法内联”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 内联是优化决策而不是语言保证，代码大小、虚调用和异常结构都会影响结果

最小示例： 当“升级运行时后某个微基准结果变化”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： ReadyToRun 在发布产物中包含预编译代码以改善部分启动场景，同时仍可由运行时继续使用 JIT

原因： 常见误区是“ReadyToRun 会彻底禁止运行时 JIT”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 产物更大且预编译代码未必适合所有热点路径，收益需要按应用测量

最小示例： 当“启用后启动更快但包体明显增大”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 框架依赖部署依靠目标机器上兼容的共享 .NET 运行时运行应用

原因： 常见误区是“框架依赖部署会把完整运行时一起复制到输出目录”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 部署前必须确认目标环境运行时版本和架构，不能只复制应用文件

最小示例： 当“目标主机未安装兼容运行时导致启动失败”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 单文件发布把应用相关文件打包为更少的部署单元，但运行时加载和本机库处理仍有特定边界

原因： 常见误区是“启用单文件就自动获得最小体积和零提取行为”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 单文件、自包含、裁剪和 AOT 是可组合但不同的发布选项

最小示例： 当“插件通过物理文件路径定位依赖失败”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 运行时类型身份不仅包含名称，还受程序集身份和所属加载上下文影响

原因： 常见误区是“只要命名空间和类型名相同就一定可以强制转换”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 两个类型显示同名也可能因来自不同加载上下文而无法转换

最小示例： 当“插件接口转换抛出类型不匹配”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 自定义加载上下文应建立确定的依赖解析策略，并避免重复加载主契约程序集

原因： 常见误区是“在 Resolving 事件中返回任意同名程序集都安全”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 解析路径必须考虑托管依赖、本机依赖和资源程序集

最小示例： 当“插件在开发机正常而发布目录缺少本机库”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 托管对象包含运行时管理信息和实例数据，字段布局还会受到对齐、平台与布局规则影响

原因： 常见误区是“字段在源码中的顺序永远等于所有平台上的物理偏移”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 未声明显式布局时不应把某次测量的字段偏移当成跨版本 ABI

最小示例： 当“通过非托管接口传递结构后数据错位”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 引用变量保存对托管对象的引用，复制引用不会自动复制目标对象

原因： 常见误区是“把引用参数按值传递会创建目标对象的深复制”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 值传递仍会复制引用值，因此两个变量可指向同一实例

最小示例： 当“方法修改对象后调用方观察到变化”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 拆箱要求目标类型与已装箱值的实际值类型兼容，并先取得其中值的托管地址再复制或使用

原因： 常见误区是“装箱后的 int 可以直接拆箱为 long”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 数值类型之间不会因可转换就自动完成跨类型拆箱

最小示例： 当“从 object 转换数值时抛 InvalidCastException”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 达到大对象阈值的分配通常进入 LOH，并由较高代回收节奏管理

原因： 常见误区是“LOH 上的对象永远不会被回收”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 阈值和压缩策略属于运行时行为，应以当前版本文档和指标为准

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

结论： 固定对象可阻止 GC 在固定期间移动其地址，便于与需要稳定指针的本机代码交互

原因： 常见误区是“固定对象会暂停整个进程的垃圾回收”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 固定时间应尽量短，跨异步等待保存裸指针尤其需要谨慎

最小示例： 当“本机调用期间指针必须保持稳定”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合

原因： 常见误区是“Server GC 在任何小型进程中都必然延迟最低”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断

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

结论： 后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响

原因： 常见误区是“开启后台 GC 后应用线程永远不会因 GC 暂停”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 某些阶段仍需要暂停托管线程，并发不代表零停顿

最小示例： 当“延迟曲线仍出现短暂停顿”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： .NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略

原因： 常见误区是“运行在容器里就会自动获得无限制内存保护”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 编排平台的 request、limit 与进程可见资源仍需用运行时指标核实

最小示例： 当“Pod 接近内存限制却没有明显托管异常”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。

结论： 裁剪警告表示静态分析无法证明动态访问安全，应定位调用链并显式表达依赖

原因： 常见误区是“警告只影响编译日志，不可能对应运行时缺失”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 消除警告不应靠全局压制，除非已经证明并记录运行时契约

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

结论： RequiresUnreferencedCode 标记调用在裁剪场景中无法由分析器保证安全，并把风险暴露给调用方

原因： 常见误区是“添加该特性会让裁剪器自动分析并修复方法内部所有反射”，它把一次现象、局部实现或有限条件扩大成普遍保证；正确判断必须回到平台契约并收集运行证据。

边界： 它是风险契约而不是自动保留所需成员的实现

最小示例： 当“库 API 在裁剪发布时产生调用警告”出现时，先记录配置、指标与调用路径，再验证主规则，不以单次成功、重启恢复或盲目扩容代替根因分析。