C# switch模式匹配：从“常量选择器”到“智能解构器”的进化
一个核心观点是：C# 的 switch 早已超越了传统意义上仅能处理整数或字符串常量的“选择器”角色。自 C# 7.0 引入模式匹配功能以来，它已进化为一个能够安全解构对象、智能检查类型、精确判断范围的“智能解构器”。然而，许多开发者仍在使用过时的语法，这不仅容易导致恼人的 NullReferenceException 空引用异常，也常因编译错误 CS8509: Not all cases are handled 而中断开发流程，迫使开发者重新学习现代模式匹配的最佳实践。
switch 表达式 vs switch 语句：一字之差，天壤之别
两者语法相似，但设计理念和适用场景截然不同，错误选择会带来维护隐患：
switch语句（使用case/break的传统形式）是一个“行动派”。它本身不产生返回值，核心用途是执行包含各种逻辑的操作流程，功能全面。其经典问题是容易遗漏break语句，导致意外的分支“穿透”——幸运的是，现代C#默认禁止此类穿透，除非开发者显式使用goto case。switch表达式（C# 8.0 及以上版本引入，形式如var result = value switch { ... };）则是一个“计算家”。它要求穷尽所有可能的输入情况，并且每个分支都必须返回一个类型一致的值。其优势在于代码简洁、支持不可变性，并能天然避免处理逻辑遗漏。但相应的限制是，它不适合执行带有副作用（例如调用方法、修改对象状态）的操作。- 简单总结：进行值映射（如状态码转换描述）优先选用表达式；处理对象初始化或包含日志记录等操作时，使用语句更为合适。
字符串类型 switch：是时候告别 == null 了
你是否还记得那种冗长的传统写法？if (s == null) ... else if (s == “a”) ...，不仅代码繁琐，还极易遗漏空值处理。现在，模式匹配让字符串判断变得异常优雅：
return s switch
{
null => “unknown”,
“” => “empty”,
“admin” => “administrator”,
“user” => “standard user”,
_ => “other”
};
这里有三个关键细节值得深入理解：
null和空字符串“”本身就是合法的模式，无需在switch外部进行额外的空值检查。- 模式
_（弃元模式）是强制性的，它作为默认情况，负责处理所有未被前面模式覆盖的输入。缺少它，编译器将报错。 - 书写顺序即匹配优先级。如果将
“”模式写在“admin”之后，那么空字符串将永远无法被正确匹配。
类型模式 + 解构：处理多态对象的“优雅公式”
假设你有一组继承自 Shape 基类的子类（如 Circle, Rectangle），需要根据具体类型计算面积。新模式下的写法极为流畅：
double GetArea(Shape shape) => shape switch
{
Circle c => Math.PI * c.Radius * c.Radius,
Rectangle r => r.Width * r.Height,
null => 0,
_ => throw new ArgumentException(“Unknown shape type”)
};
此处的精髓在于，模式 Circle c 一举两得：它首先执行了类型检查，确认输入是否为 Circle；检查通过后，它会安全地将输入转换并赋值给新变量 c，使你可以直接访问 c.Radius 等成员。这比传统的先使用 is 判断再进行强制转换，或者使用 as 运算符后判空的方法，要清晰和高效得多。如果结合 record 类型，还能实现更强大的属性解构模式，例如 Point { X: > 0, Y: ... }。
范围模式与常量模式混用：当心边界上的“陷阱”
C# 9.0 引入的范围模式（1 to 10）非常实用，但当它与常量模式混合使用时，编译器不会自动优化匹配顺序。代码的书写顺序，直接决定了它的匹配顺序：
int level = 5;
var desc = level switch
{
0 => “off”,
1 to 3 => “low”,
4 to 6 => “medium”, // level=5 会在这里被匹配
7 to 10 => “high”,
_ => “invalid”
};
使用时常需警惕以下几个“坑点”：
- 切勿将
1 to 3误写为1..4，后者是 C# 8.0 中用于集合索引的范围运算符语法，在switch模式中无效。 - 如果遗漏了常量模式
0，不要期望_弃元模式会捕获它。因为输入值0并不符合1 to 3的范围定义，结果将是直接落入_分支，导致逻辑错误。 - 若想表达“大于等于1”的条件，使用
1 to int.MaxValue略显笨拙。此时，使用带条件子句的模式var x when x >= 1 => …会更加直观和清晰。
归根结底，真正的挑战往往不在于语法细节，而在于准确判断何时应该使用 switch。如果分支逻辑中需要调用 await 异步方法、包裹复杂的 try-catch 异常处理、或者修改外部变量状态，那么 switch 可能就不再是最佳选择。模式匹配功能固然强大，但它并非万能解决方案。清晰地认识其能力边界，才能将其应用得恰到好处，编写出既高效又健壮的代码。
