match-case 仅在匹配字面量、结构化序列和嵌套字典三类可静态分析场景下比 if-elif 快10%–15%，其余情况无优势甚至更慢。
match-case 在多数日常分支判断中并不比 if-elif 快；它只在特定结构化匹配场景下有可测量的性能优势，盲目替换反而可能变慢。
match-case 真正快在哪几个具体场景
CPython 3.10+ 对 match 做了字节码级优化，但收益只出现在以下三类明确可静态分析的模式中：
- 匹配字面量（如
case 200、case "GET"）：底层用类似哈希跳转的方式，避免 if-elif 的线性比对 - 匹配元组/列表结构（如
case ["move", dir]）：一次完成类型检查 + 长度验证 + 下标解构，省去isinstance()、len()、[0]、[1]多次调用 - 匹配嵌套字典（如
case {"type": "order", "id": int(id)}）：避免反复.get("type")、.get("id")和手动类型转换
实测显示：当分支数 ≥ 7 且结构固定时，match 平均比等效 if-elif 快 10%–15%，主要来自生成更少的字节码指令。
哪些写法会让 match-case 明显变慢
这些操作会抵消甚至逆转性能优势，因为它们触发解释器回退到通用路径：
立即学习“Python免费学习笔记（深入）”；
- 在
case中加守卫（if子句），例如case x if expensive_check(x):—— 每次前面的 case 不匹配，就重复执行该函数 - 用
case str():匹配大量非字符串数据 ——isinstance(value, str)开销比type(value) is str高得多 - 对简单整数枚举硬套结构，例如
case 1 | 2 | 3 | 4 | 5:—— 实际退化为线性比对，不如value in {1, 2, 3, 4, 5} - 在高频循环内调用含深层嵌套匹配的函数 —— 模式解析本身有常数级开销，小数据+高频率下反而更重
如何验证你自己的场景是否真能提速
别信经验，直接用 timeit 测。关键是要模拟真实输入分布：
- 用和生产一致的数据类型和结构构造测试值，比如
x = {"type": "order", "id": 123, "items": [...]} - 运行命令：
timeit -s "x = {...}" "match x: case {'type': 'user'}: pass; case {'type': 'order', 'id': int(i)}: pass; case _: pass" - 同时测等效
if-elif版本，注意保持逻辑完全一致（包括.get()是否带默认值、类型转换是否遗漏） - 在目标 CPython 版本上测（3.10.0 初期版本甚至略慢于 if-elif；3.12+ 有持续优化）
真正影响响应时间的，往往不是 match 本身，而是 IDE 类型推导不准、C 扩展（如 orjson）返回对象不完全兼容匹配逻辑、或守卫里藏着未察觉的 I/O 或计算——这些隐性成本比字节码快慢更难排查。
