match case支持字典、列表、元组、命名元组、数据类及带__match_args__的自定义类；不支持字符串/数字的切分匹配，也不支持set或range直接匹配；条件判断需用case pattern if condition:守卫语法。
match case能匹配哪些数据结构
Python 3.10的match语句不是万能的“模糊搜索”，它只对可解包、有明确结构的数据做**结构化匹配**。常见支持类型包括：字典、列表、元组、命名元组、数据类（dataclass），以及带__match_args__的自定义类。
字符串、整数、浮点数等原子值只能用字面量或_通配，不能像正则那样切分匹配；比如"hello"无法拆成h, *rest——这不是语法错误，而是语义不支持。
实操建议：
- 匹配列表/元组时，用
[a, b, *rest]解包，但rest必须是最后一个元素 - 匹配字典用
{'key': value, **rest}，**rest必须在末尾且只能出现一次 - 数据类需显式定义
__match_args__或使用@dataclass装饰器（默认按字段顺序） - 避免对
set或range直接匹配——它们不支持结构解包，会报TypeError: cannot match against a set
case子句里怎么写条件判断
case本身不支持if表达式，但可以用guard（守卫）在匹配成功后加额外条件，语法是case pattern if condition:。注意condition是在模式匹配通过后才执行的布尔表达式，不是模式的一部分。
常见错误现象：把逻辑写进模式里，比如case x if x > 0 and x ——这其实没用<code>match的结构能力，纯属多余；不如直接用if。
实操建议：
- 守卫适合补充结构匹配无法覆盖的约束，例如
case Point(x, y) if x == y: - 守卫中可调用函数，但别放副作用操作（如修改全局变量），因为执行时机不可控
- 多个
case顺序重要，守卫不满足时会继续尝试下一个case，不会跳过 - 别在守卫里重复匹配逻辑，比如
case [a, b] if len([a,b]) == 2:——长度已在模式中保证
为什么我的match总是走到_分支
_是兜底通配符，但它不是“没匹配到就走这里”，而是“只要前面所有case都不满足，就一定走这里”。问题往往出在：模式写得比实际数据更严格，或者类型不一致。
典型场景：
- 想匹配
{"status": "ok", "data": [...]}，却写了case {"status": "ok", "data": [x, y]}:——但实际data可能是空列表或单元素，导致失败 - 传入的是
list，但case写了tuple模式，类型不匹配直接跳过 - 用了
case SomeClass(a, b):，但实例不是SomeClass类型，或没有定义__match_args__ - 字典匹配漏了必选键，比如
case {"code": c}:，但输入是{"code": 200, "msg": "ok"}——这没问题；但如果写成case {"code": c, "msg": m}:而输入缺msg，就会跳过
调试技巧：把_换成具体变量名（如case unmatched:），然后打印unmatched看真实结构。
match和if-elif链性能差多少
单纯比执行速度，match在多数场景下略快于等价的if-elif，尤其当分支多、模式简单时，CPython做了优化。但差异通常在纳秒级，除非热路径里每秒调用百万次，否则不用纠结。
真正影响选择的是可维护性：
- 结构匹配逻辑清晰，比如解析AST节点、HTTP响应体、配置字典时，
match比嵌套isinstance+getattr易读得多 - 编译器会对
match做穷尽性检查提示（虽然目前仅限IDE和mypy，CPython运行时不强制） - 滥用
match处理纯值比较（如case 1 | 2 | 3:）反而让代码变重，此时if x in (1, 2, 3):更直白 - 动态生成模式不被支持——所有
case必须是静态可分析的字面量或名称，没法把变量塞进case里
复杂点在于嵌套模式的可读性：三层以上的解包（如case [{"items": [Item(n, p), *_]}, *_]:）会让同行评审皱眉，这种时候该拆成多个match或退回到传统流程控制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
