c#如何使用switch语句_c#switch语句从入门到精通教程

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 可能就不再是最佳选择。模式匹配功能固然强大，但它并非万能解决方案。清晰地认识其能力边界，才能将其应用得恰到好处，编写出既高效又健壮的代码。