模式匹配可不是什么语法糖。C# 编译器在类型安全和作用域控制上，实打实地做了实质性约束——is 关键字后面跟的，不是简单的“判断条件”，而是一套“声明+约束”的组合体。变量只在匹配成功的作用域内才有效，编译器会强制隔离，从根本上杜绝误用。
什么时候该用 is + 声明模式，而不是 as + 空值检查？
当需要同时完成类型检查和变量提取时，is 声明模式比 as 方案更安全、也更简洁。它省去了 as 方案中手动判空的麻烦，也绕开了重载 == 可能带来的语义歧义。
as仅适用于引用类型或可空类型转换，失败时返回null或default，不提供作用域层面的隔离。is T x则不同：一旦匹配失败，变量x在当前作用域内根本不可见，编译器会直接报错，想误用都没机会。- 对值类型（比如
int?）用as会导致编译失败，但is int number完全合法。 - 来看个例子：
if (obj is string s && s.Length > 0)。这里s在整个&&右侧都可用，而且只在匹配成功时才存在。
switch 表达式里怎么写嵌套属性模式？
属性模式支持递归，但有个陷阱：必须确保路径上的每个成员都非空，否则运行时就会抛出 NullReferenceException。编译器不会帮你做空保护，得靠 is not null 或 ?. 来配合。
- 错误写法：
person is { Address.City: "Beijing" }—— 如果Address是null，程序直接崩溃。 - 正确写法：
person is { Address: { City: "Beijing" } }。但前提是Address类型已知且非空。如果它可能为null，就得拆成两层：person is { Address: not null } and { Address.City: "Beijing" }。 - 更稳妥的做法是结合逻辑模式：
person is { Address: { City: "Beijing" } } or { Address: null }。不过要注意，这会改变语义。 - 另外，属性名必须拼写准确，对应属性需要有 public getter，私有字段不参与匹配。
为什么 is not null 比 != null 更推荐？
这是一个最常见的面试题，也是实际开发中容易踩坑的地方。！= null 的表现取决于类型是否重载了 == 运算符，而 is not null 是语言级的空检查，不调用任何用户代码，行为确定，性能一致。
- 对于自定义类，如果重载了
==但没处理null，obj != null可能抛出NullReferenceException。 is not null对所有引用类型、可空值类型（T?）都适用，编译期就能验证合法性，非常可靠。- 它还能和类型模式组合，一次完成非空判断和类型提取：
if (str is not null and string s)。 - 不过得注意：如果启用了可空引用类型，
is not null对非可空引用类型来说是冗余的，编译器会给出警告。
常量模式和关系模式混用时的优先级陷阱
C# 的模式优先级规则，并不像数学直觉那样简单。例如，is >= 18 and <= 60 是合法的，但 is 18 or 19 or 20 不合法——or 不能直接用于多个常量，必须改用逗号分隔的列表模式或 switch 表达式。
- 关系模式（
>=、<等）只能出现在属性模式或类型模式内部，不能单独放在is右侧。 - 想匹配多个离散值，用
switch最自然：age switch { 18 or 19 or 20 => "teen", _ => "other" }。 - 在
if中模拟多值匹配，可以用is 18 or is 19，但这是两个独立的判断，不是单个模式。 - 列表模式（C# 11+）支持
is [18, 19, 20]，但仅适用于IReadOnlyList或数组，不适用于单个整数。
最容易被忽略的一点是：所有模式匹配都发生在编译时类型系统的约束下。运行时的对象类型，如果与编译时类型没有继承或实现关系，再复杂的嵌套模式也匹配不上——别指望靠模式匹配绕过类型系统的基本规则。
