C# 模式匹配全解:原理、用法与易错点
引言
随着C#
不断发展,"模式匹配"(Pattern Matching)已经成为让代码更加友好、可读和强大的核心特性。从 C#
7.0 初次引入,到 C#
11 的能力扩展,模式匹配为处理类型判断、属性解构、集合匹配等提供了简洁、高效且类型安全的表达方式。它不仅能让 if/switch 等控制结构变得“声明式”,还能带来性能提升。在这篇文章里,我们将深入剖析 C 的所有模式匹配语法和用法,追踪其演变,讲清一些容易混淆和误用的地方,让大家能了解模式匹配本质。
1. 什么是模式匹配
模式匹配本质上是一种表达式判定工具:用以检查一个对象是否与某种“模式”相吻合,如果吻合,还允许对其分解、绑定成员变量。这可以是类型检查、常量判断、属性结构匹配等。
传统 C#写法:
模式匹配写法:
更简洁、可读、类型安全,不需要重复显式强制转型。
2. C#7.0 初代模式匹配特性
2.1 Null 模式与常量模式
C#7.0 首先支持了用is
直接与 null 以及常量对比:
注意:常量匹配仅支持编译期常量,比如数字、字符串、bool、enum、const 字段和 null。不能直接用非 const 变量或表达式。
这个限制为何存在?
编译器要保证 switch 和 if 全覆盖检查,如果允许变量参与,则难推导 exhaustiveness(全覆盖)。
也可避免不可预期的副作用与逻辑混乱(比如变量运行期改变等)。
2.2 类型模式与变量捕获
类型模式允许 you not only 判断类型,还能直接捕获变量:
甚至可以链式判断:
非常适用于临时变量创建、减少强制类型转换(显式 as/cast)代码杂音。
is
vs as
?
is
结合新模式后可以直接安全声明变量,无需后续 null 检查。as
后还得写if (x != null)
。
2.3 Discard 与 var 模式
Discard(
_
):匹配但忽略,用于 switch 的 default 分支或类型“只是判断,不关心值”。var:总是匹配成功,并引出变量。通常用于解构场景,比如 switch/case 匹配对象成员。
⚠️ 这里容易误用!
不要用 var 跳过 null 检查。因为这样会把 null 值“吞掉”,造成 NullReferenceError 隐患。
2.4 switch 语句的模式匹配
传统 switch 只能匹配简单的枚举或数字等,C#7.0 后支持以下写法:
某类型满足条件即分支命中
Discard
case IEnumerable<T> _:
default 处理剩余情况
switch 的 when 子句
when
只能用于 switch:
无法用于 if!
3. C#8.0: Switch 表达式、属性、位置、元组模式
3.1 表达式 Switch
C#8 引入 switch-表达式,极大提升 switch 可读性和函数式编程体验:
匹配分支是表达式,不能有多条语句
=>
右边直接返回值,非常适合表达式体成员:
3.2 属性模式 (Property Patterns)
可直接针对属性表达式判定
重点说明:
{ }
代表对象非 null。{ Width: 10, Height: 5 }
同时要求 2 个属性等于指定值。{ Width: var x, Height: >5 }
可以对属性用关系操作和抽取变量。若对象有
Deconstruct
方法,可用位置/元组模式更优雅。
3.3 位置模式(Positional Patterns)
利用 Deconstruct 抽取变量:
用于解构类对象(类似元组)
写法类似解构元组
3.4 元组模式
处理多个参数的模式组合:
有效解决“复杂组合条件冗长”的老大难。
更直观表达多变量匹配,不需层层嵌套。
4. C#9.0: 组合、括号及关系模式
4.1 组合模式(and/or/not)
组合条件极其强大:
等价于:
not 语法
比传统 !(obj is null)
更直观。
4.2 关系模式(Relational Patterns)
直接用 >, <, >=, <= 表达区间
结合属性/类型模式:
4.3 类型模式精简
C#9 类型模式无需 underscore,eg:Rectangle
直接写。
5. C#10.0: 扩展属性模式
支持嵌套点表达式:
之前版本:
C#10:
让属性链判定更加直观简洁。
6. C#11.0: 列表与切片模式
6.1 列表模式
让数组/集合结构模式判定成为可能:
[..]
: 切片模式,等价于“0 个或多个元素”_
: 忽略一个元素(discard)
注意:切片只能出现一次。
6.2 列表递归
可以做嵌套匹配:
6.3 支持的结构
只要类型有 Length
/Count
属性和支持 [index]
则可用列表模式,如 string、数组、自定义集合(只需这两个成员)。
例如处理国别码:
7. 模式匹配背后的实现与性能分析
7.1 不是“魔法”,而是 IL 优化
许多人以为 pattern matching 是一种基于反射或者表达式树的黑魔法。实际上,编译器常常能把很多 pattern 匹配转为高效的“顺序判断”或“跳表”等机器码。
例如:
编译后 Equals:
对于一组常量匹配:
编译器会变换成:
即用范围短路、减少 equals 判断次数。
⚠️ 建议:
对于性能敏感代码,请结合 Benchmark.NET 做实测对比。有时手写的判定和 pattern matching 效果类似,甚至后者更优。
8. 常见误区与最佳实践
8.1 不要用 pattern 替代多态
最容易见的误用是用模式匹配处理继承结构的多态行为:
事实上,应该优先用抽象基类/接口的虚方法或属性:
为什么?
可扩展性强(新子类无需修改 Area 逻辑,符合开闭原则)。
虚调用比类型判定快。
更少维护负担。
8.2 Constant-Only 限制
只有编译期常量才能用于模式匹配,如果需要支持运行时变量,需采用传统判定。
8.3 避免滥用 var/discard
不要用
is var x
跳过 null 检查。discard
_
只适合确实不关心值的场景,用后不要尝试访问。
8.4 List/Slice 模式性能
使用 [..var arr, x]
这种 slice+变量捕获,编译器可能分配新数组,造成性能下降。大数据集合应谨慎。
9. 小结与展望
Pattern Matching 是现代 C# 代码的“瑞士军刀”,能极大提升 if/else、switch/case 类代码的简洁性、表达力和类型安全性,在 switch 表达式等场景下优势更加明显。它不仅代码层面更美观,也能为某些条件分支提供更优指令级性能。然而,模式匹配并非多态(polymorphism)、虚方法的替代品!业务逻辑与类型分发仍建议用面向对象原则解决。
当前最大限制为:只能用常量做模式判定,变量(非编译期 const)不支持,理由有 exhaustiveness 推导、避免副作用等。后续版本是否会提升,还需 C# 团队权衡设计复杂性。
未来,随着 C# 特性继续演进(如 pattern 泛型化、任意表达式匹配),我们有理由期待模式匹配变得更加强大和灵活。如果你还没用过模式匹配,是时候投入生产实践试试啦!
文章转载自:InCerry
原文链接:https://www.cnblogs.com/InCerry/p/-/introduce-cs-pattern-match
评论