match-case适合处理输入结构明确、分支依据清晰的清洗逻辑，如API固定枚举字段、CSV预定义status列、JSON已知schema嵌套对象；不适用于正则提取、模糊匹配或空值/混合类型原始日志。
直接用 match-case 替换嵌套 if-elif-else 处理数据分类清洗，能显著提升可读性与维护性——但前提是结构化程度够高、类型/形状可判别；对自由格式字符串或动态字段，硬套 match 反而增加歧义和运行时错误风险。
match-case 能安全接管哪些清洗场景？
它适合处理「输入结构明确、分支依据清晰」的清洗逻辑，比如：API 返回的固定枚举字段、CSV 中预定义的 status 列、JSON 中已知 schema 的嵌套对象类型。不适用于需要正则提取、模糊匹配或字段存在大量空值/混合类型的原始日志行。
-
match的case分支必须是可静态判断的模式（字面量、元组、类实例、带守卫的条件），不能是任意函数调用或变量引用 - 常见可用模式：
case "active"、case {"status": "error", "code": int() as c}、case [str(), int(), *_] - 若原始数据含
None或缺失键，需先做isinstance()或get()防御，否则match会跳过所有case进入case _
如何写带守卫（guard）的 case 处理数值范围或复合条件？
清洗中常需按数值区间分桶（如 score ≥ 90 → "A"）、或组合多个字段判断（如 status == "pending" and retry_count > 3）。这时不能只靠字面匹配，得用 if 守卫。
match data:
case {"score": s} if s >= 90:
return "A"
case {"score": s} if s >= 80:
return "B"
case {"status": "pending", "retry_count": r} if r > 3:
return "blocked"
case {"status": "archived"}:
return "skip"
case _:
return "unknown"
注意：if 守卫里不能修改变量（如 s += 1），且所有守卫表达式必须为 True 或 False；若守卫抛异常（如 s.upper() 对 int），整个 match 会直接报错，不是跳到下一个 case。
立即学习“Python免费学习笔记（深入）”；
为什么用 class pattern 比 dict pattern 更可靠？
当清洗逻辑依赖字段组合+类型约束（如要求 user_id 是 int、email 是非空 str），用自定义类配合 __match_args__ 能在匹配时自动校验类型，避免 dict 中字段存在但类型错（如 "user_id": "123"）导致后续逻辑崩溃。
class UserRecord:
__match_args__ = ("user_id", "email")
def __init__(self, user_id: int, email: str):
self.user_id = user_id
self.email = email
<h1>清洗时：</h1><p>match record:
case UserRecord(user_id, email) if "@" in email:
return {"valid_id": user_id, "domain": email.split("@")[1]}
case UserRecord():
return {"error": "invalid<em>email"}
case </em>:
return {"error": "not_a_UserRecord"}
- dict pattern（
{"user_id": int(), "email": str()}）无法阻止"user_id"是 float 或 str，而 class pattern 在构造时就强制了类型 - 若原始数据是 dict，需先用
UserRecord(**data)尝试转换——失败就进case _，这一步不可省略
真正难的不是写对 case，而是决定哪些数据该在 match 前标准化（如统一空值为 None、把字符串数字转 int）、哪些该留在守卫里动态判断。没做这层准备，match 很快就会变成一堆 case _ if ... 的拼凑体。
