C# CS8602 — 可能对 null 引用解引用

症状

遇到“C# CS8602 — 可能对 null 引用解引用”时靠猜测只会浪费时间。请按证据排查：先复现症状，再执行针对性诊断，定位根因后修复，并用明确检查验证结果。

可观察到的症状包括：

• Warning CS8602: Dereference of a possibly null reference
• 仅在启用可空引用类型后出现警告
• 抑制一处警告后它又出现在后续行

诊断

先在隔离环境中复现故障，再按顺序执行以下检查，逐步缩小范围。

步骤 1

dotnet build /p:TreatWarningsAsErrors=true -warnaserror:CS8602

把警告升级为错误可精确定位行号并防止它游移。

步骤 2

dotnet build -warnaserror 2>&1 | grep CS8602

警告行会显示分析器认为哪个值可能为 null。

常见诱因（按出现频率排序）：

• 启用了可空引用类型，且该值确实可能为 null
• 辅助函数返回可能为 null 的值，调用方却解引用
• 存在 null 检查但编译器无法跨方法边界追踪

根因

启用可空引用类型后，编译器会跟踪 null 状态流。当分析器无法在该路径上证明值非 null 时，解引用即触发 CS8602。

修复

添加显式 null 检查并提前返回或抛错，使用 is not null 模式，并把 null 包容 ! 仅保留在由构造保证非 null 处，并加简短注释说明原因。

注意：滥设 null 包容运算符会把编译期警告变成运行期 NullReferenceException。

public string Greet(User? user)
{
    if (user is null)
        throw new ArgumentNullException(nameof(user)); // flow: non-null after

    return $"Hello, {user.Name}";
}

// only when non-null is guaranteed by construction
var name = cache["user"]!.Name; // cache seeded above; safe by contract

验证

以警告即错误构建并确认 CS8602 消失；补充传入 null 的单元测试，断言受控的 ArgumentNullException 或默认行为。

修复后补充一条回归测试，复现原始症状，防止问题再次出现。

这类故障通常是环境问题而非纯逻辑错误，因此在缺陷记录中应写明完整命令、环境变量与工作目录。请用最小的脚本复现，待最小用例清楚后再扩大范围。为这类故障准备一份简短的排查清单，能显著减少下次排障时间。