核心控制点是Nullable项目属性和#nullable预处理器指令：前者全局控制注释与警告上下文，后者逐文件精细切换；enable使string默认非空并启用全部null警告，disable则完全退回到C#7行为，误配将导致警告失效或误报。
直接说结论：在 C# 项目中启用或禁用可空引用类型检查，核心控制点是 Nullable 项目属性和 #nullable 预处理器指令，二者作用范围不同、不可互相替代——误配会导致警告不触发、或大量误报。
如何在 .csproj 中全局启用/禁用 Nullable 检查
这是最常用也最容易出错的入口。必须明确：Nullable 属性同时控制「可空注释上下文」和「可空警告上下文」两个维度，不是简单的“开/关”开关。
-
enable：所有引用类型默认非空（string≠string?），启用全部 null 相关警告（如CS8602、CS8600） -
warnings：不改变类型语义（string仍等价于string?），但对明显解引用 null 的代码（如obj?.ToString()后又直接调用obj.ToString()）发出警告 -
annotations：类型语义生效（string表示非空），但关闭所有 null 警告——适合想先加注释再逐步处理警告的团队 -
disable：完全退回到 C# 7 及以前行为，编译器不识别?或!，也不报任何 null 相关警告
常见错误：只改了 LangVersion 却漏加 Nullable，结果 string? 被当成语法错误；或设成 warnings 后发现 string name = null; 不报警，误以为功能没生效。
为什么 #nullable enable/disable 必须写在文件顶部
#nullable 指令是**逐行生效**的，且只影响其后的代码行。如果写在中间或函数体内，编译器会直接忽略（不报错，但无效）。
- 正确位置：
#nullable enable必须是 .cs 文件中第一个非空白、非注释的行（//注释前也可） - 典型误用：在
using块之后、类声明之前插入#nullable disable，结果整个类仍在可空上下文中，导致string? x;报错 - 迁移旧文件时，常需在顶部加
#nullable disable暂时屏蔽警告，但后续要逐段删掉它——不能长期依赖
注意：#nullable restore 会恢复到文件所在项目的默认 Nullable 设置，不是回退到上一个 #nullable 指令。
什么时候该用 ! 运算符，以及它为什么危险
! 是“空值断言”，不是“空值忽略”。它告诉编译器“我保证这里不为 null”，但运行时不做任何检查。
- 合法场景：调用返回
string?的 API 后，你已通过if (x != null)或??显式处理过，但编译器流分析未覆盖到（比如跨方法、异步回调） - 高危场景：对
Configuration["key"]、Request.Query["id"]等外部输入直接加!，等于把空指针风险从编译期推到运行时 - 替代方案优先级：先用
??提供默认值 → 再用?? throw显式失败 → 最后才考虑!
示例：var name = config["name"]!; 看似简洁，但一旦配置缺失，就是 NullReferenceException；而 var name = config["name"] ?? "unknown"; 更安全、意图更清晰。
混合使用时最容易被忽略的兼容性陷阱
当项目中同时存在 Nullable 设为 enable 的新文件和顶部带 #nullable disable 的旧文件时，跨文件调用会出现静默行为差异。
- 从
#nullable disable文件调用enable文件中的方法，参数类型若为string，传null不报警；但该方法内部若解引用该参数，仍可能触发CS8602 - 反向调用时，
enable文件中接收string?参数的方法，被disable文件调用传null，编译器不会警告，但逻辑可能崩 - 第三方 NuGet 包若未标注可空性（即无
[AllowNull]、[NotNullWhen(true)]等属性），其 API 在可空上下文中会被默认视为maybe-null，容易引发过度警告
真正难处理的从来不是语法开关，而是类型边界——尤其是配置读取、JSON 反序列化、数据库映射这些天然带空值的环节。别指望 Nullable 一键解决所有问题，得配合具体数据流做针对性断言或防御。
