C# 中 switch => 表达式如何简化多分支逻辑并避免 null 异常？

Question

在使用 C# 的 `switch` 表达式（`switch =>`）处理多分支逻辑时，若输入值为 `null` 且未显式处理 `null` 情况，易触发 `NullReferenceException` 或逻辑遗漏（如 `string? status = null; var result = status switch { "A" => 1, "B" => 2, _ => 0 };` ——此处 `_` 会匹配 `null`，看似安全，但若分支中误调用 `.Length` 等成员，或与可空引用类型（如 `string?`、`int?`）混用模式匹配（如 `"A" when value.Length > 0`），仍可能因解引用 `null` 崩溃。更隐蔽的是：当 `switch` 表达式作用于泛型参数 `T` 且 `T` 为引用类型时，`case null:` 语法虽存在，但开发者常忽略其必要性，或误以为 `default` 可覆盖所有边界情况。如何在保持表达式简洁性的同时，**强制、清晰、零成本地防御 null 输入，并确保每个分支的执行上下文安全？**

Answer 1

```html

一、现象层：null 在 switch 表达式中的“伪安全”陷阱

开发者常误认为 _ => 0 能兜底 null，实则它仅匹配“未被前面 case 捕获的任意值”，而 null 作为引用类型字面量，在模式匹配中不触发任何字符串/值语义分支，却会落入通配符——看似执行了，实则埋下隐患：

• status switch { "A" => status.Length, _ => -1 } → NullReferenceException
• 泛型方法 T Process<T>(T input) where T : class 中，input switch { null => ... } 是合法语法，但 case null:（语句式）与 null =>（表达式式）易被混淆或遗漏

二、机制层：C# 编译器如何解析 switch 表达式的 null 匹配

根据 C# 8+ 语言规范，switch 表达式对 null 的处理遵循静态类型驱动的模式优先级：

输入类型	匹配行为	典型风险
string?	null 可被 null => 或 _ => 捕获，但 "A" when x.Length > 0 中 x 为 null 时 when 子句不执行（短路），不会崩溃	误以为 when 安全，实则分支体仍可能解引用
object / 泛型 T where T : class	null 仅匹配 null =>；若缺失该分支，且存在 _ =>，则 null 被捕获，但分支内若调用 .ToString() 等将崩溃	编译器不警告，运行时才暴露

三、防御层：零成本强制 null 防御的四大实践范式

1. 显式 null 分支前置（推荐）：
   status switch { null => throw new ArgumentNullException(nameof(status)), "A" => 1, "B" => 2, _ => throw new ArgumentException($"Invalid status: {status}") }
2. 契约式预检 + 不可空断言：
   Debug.Assert(status != null); status switch { "A" => 1, ... }（仅 Debug，零成本 Release）
3. 泛型约束 + null-forgiving 运算符协同：
   static int Map<T>(T? value) where T : class => value switch { null => 0, T t when t is string s => s.Length, _ => -1 };
4. 扩展方法封装防御协议：
   public static T NullGuard<T>(this T? value, string paramName) where T : class => value ?? throw new ArgumentNullException(paramName);
   使用：status.NullGuard(nameof(status)) switch { ... }

四、架构层：构建可复用的 null-safe switch 基础设施

定义类型安全的匹配抽象，消除重复防御逻辑：

public static class SafeSwitch
{
  public static R Match<T, R>(this T? value, 
    Func<R> @null, 
    params (Func<T, bool> predicate, Func<T, R> handler)[] cases)
    where T : class
  {
    if (value is null) return @null();
    foreach (var (pred, handler) in cases)
      if (pred(value)) return handler(value);
    throw new InvalidOperationException("No matching case");
  }
}
// 使用：status.Match(() => 0, (s => s == "A", _ => 1), (s => s == "B", _ => 2));

五、演进层：C# 12+ 趋势与静态分析增强

未来可通过以下方式实现更深层防御：

• 启用 #nullable enable 后，Roslyn 分析器可识别 _ => x.Length 中 x 可能为 null 并提示 CS8602
• 自定义 Analyzer 检测缺失 null => 分支（尤其在泛型方法或 class 约束参数上）
• Source Generator 生成带 null guard 的 switch 封装器，如 [NullGuardedSwitch] 属性

六、验证层：单元测试覆盖 null 边界场景

必须包含的测试用例（xUnit 示例）：

[Theory]
[InlineData(null)]
[InlineData("A")]
[InlineData("Z")]
public void SwitchExpression_HandlesNull_Safely(string status)
{
  // Act & Assert
  var ex = Record.Exception(() => status switch { null => 0, "A" => status.Length, _ => -1 });
  Assert.Null(ex); // 不应抛出 NRE
}

七、决策流程图：何时采用哪种 null 防御策略

graph TD
  A[输入是否为泛型 T where T:class?] -->|是| B[必须显式 null => 分支]
  A -->|否| C[是否高吞吐核心路径?]
  C -->|是| D[使用 Debug.Assert + Release 忽略]
  C -->|否| E[使用扩展方法 NullGuard]
  B --> F[是否需统一错误语义?]
  F -->|是| G[封装 SafeSwitch.Match]
  F -->|否| H[内联 null => throw]

```