.NET 11 搭配默认的 C 15，核心变化就是把很多以前要跑到线上才会炸出来的 Bug，放到编译阶段直接检查，编译器不再只是简单做语法校验，而是新增一套更强的穷尽性分支检查、内存安全规则、代码分析器，从根源减少漏分支、类型匹配错误、不安全内存访问这类高频坑。很多开发者平时踩坑最多的场景，就是新增枚举或者联合类型之后，switch 分支忘了同步补上，上线之后触发默认分支或者直接抛异常，这一次的编译器检查专门瞄准这类问题；同时配套更新的代码分析器、unsafe 安全模型，也能减少误报，给出更精准的提示，不用等测试、不用等到生产环境复现，在 build 的环节就能看到风险。下面把编译器新增查错能力、配套特性、开启方式、迁移注意点拆成清单和表格，方便直接上手调试。
一、编译器新增核心查错能力清单
- 联合类型（Union Types）穷尽检查
- 封闭层级 Closed hierarchies
- 内存安全模型（预览）
- 代码分析器优化 CA1873
- 逻辑运算符静态校验
新增联合类型，当你用 switch 匹配时，编译器强制校验有没有覆盖全部子类型，新增类型之后，所有没补齐分支的 switch 直接告警，不会等到运行时才漏掉分支。
用 closed 修饰类，只允许在当前程序集派生，编译器掌握全部子类，switch 不用写 default，依然可以完成完整覆盖检查，少写兜底分支同时避免遗漏。
重新梳理 unsafe 边界，把不安全标记绑定到真正访问非托管内存的操作，而不是整个方法；新增 safe 关键字，让安全外部方法明确标记，更容易在编译阶段发现内存越界风险。
日志开销分析器大幅降低误报，不再乱标记属性读取、GetType 这类常规代码，告警信息直接说明风险原因，方便快速定位高开销日志代码。
接口类型和 dynamic 混用 &&、||，编译阶段直接报错，不再编译通过、运行时报 RuntimeBinderException。
二、配套：JIT 与运行时辅助能力
除了静态查 Bug，JIT 也做大量优化，在编译期消除隐患和冗余代码。
| 优化项 | 作用 | 对开发的好处 |
|---|---|---|
| 边界检查消除 | 自动判定数组下标安全，移除多余越界检查 | 提升性能，同时减少人为边界错误 |
| 冗余 checked 移除 | 去掉不会溢出、多余的溢出检查 | 减少不必要开销 |
| 去虚拟化、分支折叠 | 合并固定分支，消除死代码 | 死代码更容易被静态扫描发现 |
| Runtime Async | 运行时托管异步状态机 | 堆栈信息更干净，异步类 Bug 调试更容易 |
三、开启全套编译器 Bug 检测实操步骤
- 升级 SDK：安装 .NET 11 SDK，项目把 TargetFramework 设置为 net11.0，默认自动启用 C# 15。
- 配置分析器等级：在项目文件里把分析器告警级别改成 Warning 或者 Error，让漏分支、不安全代码阻断编译。
latest
true
- 按需开启预览特性：内存安全模型属于预览功能，需要单独开启；联合类型、封闭层级不需要预览开关。
- 本地编译验证：执行 dotnet build，观察编译器输出，优先修复穷尽性警告、内存安全告警。
- CI 流水线同步升级：CI 环境同步升级 .NET 11，把编译告警拦在合并代码之前。
- 灰度迁移：老项目可以先升级语言版本，逐步修复编译器抛出的告警，不要一次性强制全量改成报错。
四、适合这套静态检查的业务场景
- 状态机、订单流程、权限判断，大量使用 switch /switch 表达式；
- 底层 SDK、高性能组件、和非托管代码交互，需要管控 unsafe；
- 日志量大的后端服务，想要提前发现高开销日志逻辑；
- 开源库、公共组件，希望在编译阶段就减少版本迭代引入的破坏性漏分支 Bug。
五、限制和容易踩的坑
- 不是所有 Bug 都能抓到：空引用、网络异常、业务逻辑错误这类，编译器依然无法预判；
- 内存安全模型目前是预览，API 和规则后续版本还有变动，正式业务谨慎直接上；
- 老项目大量遗留 switch，如果依赖 default 兜底，升级后会批量爆出告警，需要分批整改；
- 第三方库如果还没有适配 C#15，升级之后有可能出现版本兼容告警。
【相关 FAQ】
问题 1：.NET 11 的编译器静态检测，主要可以提前发现哪一类 Bug？
回答 1：.NET 11 的编译器静态检测重点捕获 switch 分支遗漏、联合类型匹配不全、不安全内存访问、日志冗余开销、dynamic 和接口逻辑运算符混用这类原本容易放到运行时才暴露的 Bug。
问题 2：升级到 .NET 11 之后，编译器的穷尽性检查要不要额外开启？
回答 2：项目目标框架设置 net11.0，默认使用 C15，联合类型、封闭层级对应的 switch 穷尽检查默认启用，只需要调整分析器级别，就可以把警告升级为编译报错。
问题 3：.NET 11 编译器新增的内存安全检查，能不能直接用在生产项目？
回答 3：.NET 11 的这套内存安全模型属于预览特性，虽然编译器可以提前识别 unsafe 边界风险，但规则还有调整空间，生产项目建议先做评估，不建议直接大规模启用。
问题 4：已经在用 .NET 8 /.NET 9 的老项目，迁移到 .NET 11 之后，编译器查 Bug 的成本高吗？
回答 4：老项目迁移到 .NET 11，大部分代码可以正常编译，主要工作量集中在大量依赖 default 兜底的 switch 代码，编译器会批量抛出分支不全告警，可以先把告警设为提醒，分批修复，不用一次性全部改成报错阻断发布。
【参考资料】
[2026-11-11]（.NET 11 来了：你写的 bug，编译器这次先替你看到了）阿里云开发者社区
[2026-11-03]（.NET 11 SDK 新功能）Microsoft Learn
[2026-10-16]（.NET 11 新功能总览）Microsoft Learn
[2026-10-15]（What's new in C 15）Microsoft Learn
[2026-08-14]（C compiler breaking changes since C 14）Microsoft Learn
[2026-07-21]（.NET 11 预览版新特性）Microsoft Learn
【免责声明】
本文内容为 .NET 11 编译器静态检测特性技术科普；.NET 11 当前为 RC 候选版本，正式版功能、分析器规则、预览特性可能还有微调；编译器静态检查不能覆盖全部业务 Bug，上线前依旧需要单元测试、集成测试；开启 TreatWarningsAsErrors 会改变编译阻断逻辑，老项目升级前务必在测试环境验证；文中性能、检测效果受代码结构、项目配置影响。