当需同时进行类型检查和变量提取时，应优先使用 is 模式匹配而非 as + null 检查，因其更安全、简洁，且能直接绑定非空变量，避免 as 对值类型失效或泛型场景下的隐晦错误。
什么时候该用 is 模式匹配而不是 as + null 检查
当你要同时做类型检查和变量提取时，is 模式匹配比先 as 再判空更安全、更简洁。尤其在处理继承结构或接口实现时，as 会静默返回 null（对值类型还编译不过），而 is 能直接绑定非空变量。
- 用
is string s可以一步完成“是不是string”+“如果是，把值赋给s”，且s在作用域内保证非null -
as对可空值类型（如int?）或泛型约束不明确的场景容易出错；is支持is int? i这类写法，语义清晰 - 注意：
is后面跟类型模式时，不会调用用户定义的转换操作符——它只做运行时类型检查，不是强制转换
switch 表达式中用模式匹配替代传统 if-else 链
当分支逻辑基于对象类型、属性值或结构形状时，switch 表达式配合模式能显著提升可读性和维护性，且支持穷尽性检查（编译器会警告遗漏的已知子类型）。
- 基础写法：
obj switch { Person p when p.Age >= 18 => "adult", Person p => "minor", _ => "unknown" } - 必须写
_ => ...或覆盖所有已知派生类型，否则编译报错（C# 12 在 sealed 层级下更严格） - 避免在
when子句里放副作用代码（比如修改状态），因为匹配顺序不保证执行顺序，且可能被 JIT 优化掉未命中的分支 - 对
record或解构友好的类型，可用属性模式：Point { X: > 0, Y: "fourth quadrant"
使用 var 模式和弃元模式时的常见误用
var 模式（is var x）看似万能，但实际只做非空检查，不校验类型；弃元（_）虽省事，却可能掩盖本该处理的边界情况。
-
obj is var x等价于obj != null，哪怕obj是default(int)（即 0）也会失败——因为值类型不能为null，var模式只对引用类型有意义 - 写
obj is _只是恒真判断，几乎没用；真正该用弃元的是在元组或解构中忽略部分值，例如(x, _) is (1, _) - 在
switch中过度依赖_会导致逻辑漏洞：比如处理Shape的子类时，漏掉新添加的Triangle，编译器无法提醒你
模式匹配与泛型、可空引用类型的交互陷阱
泛型类型参数的擦除机制和可空引用类型（NRT）的静态分析会让模式匹配的行为变得隐晦，尤其在库作者视角下容易写出表面正确但运行时崩掉的代码。
- 对泛型方法中的
T使用is string s，若T实际是int，该分支永远不命中——但编译通过，因为类型检查发生在运行时 - 开启 NRT 后，
string?和string在模式中表现不同：is string s不匹配null，但is string? s可以（前提是s声明为string?） - 反序列化后对象字段为
null，但类型声明为非空（如public string Name { get; set; }），此时is string s仍为false——模式匹配看实际值，不看可空注解
模式匹配不是语法糖，它改变了控制流的语义边界。最常被忽略的是作用域绑定规则：用 is 绑定的变量只在当前 if 或 switch 分支内有效，跨分支复用要显式声明；还有就是对装箱值类型的匹配，int i = 5; object o = i; o is int j 成立，但 o is long k 不成立——底层还是靠 GetType()，不是数值转换。
