match-case 不能直接替代 if-elif 链做 HTML 标签判断，因 BeautifulSoup 返回小写字符串标签名，需统一用 case "div": 等字符串字面量；而状态码匹配则适合用 match-case，支持元组和守卫表达式。
Match-Case 不能直接替代 if-elif 链做 HTML 标签判断
直接拿 match 去匹配 bs4.Tag 对象或 element.name 字符串看似可行，但容易掉进类型不一致的坑里。Beautiful Soup 返回的标签名是字符串（如 "div"、"a"），而你可能误写成符号字面量（如 div）或带引号的模式不统一。
常见错误现象：SyntaxError: invalid syntax（漏写冒号）、TypeError: cannot match against variable name（把 case div: 当成变量而非字面量）。
- 必须用字符串字面量：
case "div":，不是case div:或case "DIV":（HTML 标签名默认小写） - 如果解析时用了
lower()统一处理，就保持整个match分支都用小写；否则需提前标准化 - 避免在
case中调用函数（如case element.name.upper():）——Python 3.10 不支持运行时表达式作为模式
用 match-case 处理不同响应状态码的解析分支
爬虫常需根据 response.status_code 决定后续动作：200 解析、404 跳过、503 重试、403 换 UA。这时 match 比长 if/elif/else 更清晰，且支持元组匹配。
示例场景：请求返回后立刻分发处理逻辑
立即学习“Python免费学习笔记（深入）”；
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
match response.status_code:
case 200:
return parse_html(response.text)
case 404 | 410:
logger.warning("Page gone: %s", url)
return None
case 403:
raise PermissionDenied("Blocked by server")
case code if 500 <= code < 600:
raise RetryException(f"Server error {code}")
case _:
raise UnexpectedStatus(f"Unknown status {response.status_code}")
-
case 404 | 410可合并多个离散值，比写两行elif干净 - 守卫条件（
case code if ...）适合范围匹配，但注意变量名code必须在match表达式中绑定（这里response.status_code是单值，所以用别名承接） -
case _:是兜底，不是else:—— 它不隐含“其他所有”，而是“未被前面任何 case 匹配到的值”
解析 JSON API 响应时，用 match-case 区分 data/error 字段结构
很多 API 返回结构不固定：成功时有 data，失败时有 error 或 code。用 match 解构字典比层层 if "data" in resp 更安全。
关键限制：Python 3.10 的 match 支持字典解构，但仅限字面键名 + 字面值或捕获变量，不支持嵌套解构或类型检查。
- 正确写法：
case {"data": d}:—— 成功提取d；case {"error": e, "message": m}:—— 同时捕获两个字段 - 错误写法：
case {"data": dict()}:（不支持类型构造器）、case {"data": {...}}:（不支持嵌套字典模式） - 若 API 返回字段名动态（如
"result"/"payload"），先归一化字段名再match，否则得回退到传统判断
match-case 在异步爬虫中的使用边界
在 async def 函数里用 match 没问题，但它本身不改变执行模型。别指望靠 match 自动并发或调度任务。
容易被忽略的点：
-
match是同步语法糖，不会帮你 await —— 若某个case分支里要await fetch_detail(url)，必须显式写await - 不要在
case中直接写复杂表达式（如case process_response(await resp.json()):），会破坏可读性且无法调试 - 若解析逻辑本身耗时（如正则提取、XPath 执行），
match只负责路由，性能瓶颈仍在具体解析函数里
重构时真正省下的不是 CPU 时间，而是维护成本：当新增一种响应类型（比如加个 "cached": True 字段），只需加一个 case 分支，不用翻遍 if 链找插入位置。
