if-else嵌套超三层或分支≥5时应重构，主因是易漏else、逻辑易错、测试难覆盖；推荐字典映射（适用于确定值分发）或match-case（Python 3.10+模式匹配），但依赖逻辑、共享状态或需提前退出时应选策略模式等更合适设计。
if-else 嵌套超过三层，或分支数 ≥ 5，基本就该重构了——不是为了“显得高级”，而是避免漏掉 else 分支、改错逻辑、测试覆盖难。
用字典映射替代简单条件分发
适用于：输入是确定值（字符串、数字、枚举），每个分支执行独立函数或返回固定值，且无复杂前置判断。
常见错误现象：KeyError 报错、忘记加 get() 默认值、把可变对象（如列表）当键用。
实操建议：
- 键必须是不可变类型，优先用
str或int，别用list或dict - 用
.get(key, default_func)而非直接[key]，防崩溃 - 函数值推荐用
lambda或已定义函数，别在字典里写多行逻辑 - 初始化建议放在模块顶层或类的
__init__中，避免重复构造
示例：
立即学习“Python免费学习笔记（深入）”；
def handle_login(user_type):
handlers = {
"admin": lambda u: f"Grant full access to {u.name}",
"guest": lambda u: f"Read-only for {u.name}",
"trial": lambda u: f"Limit 7 days: {u.name}"
}
return handlers.get(user_type, lambda u: "Unknown user type")(user)
Match-Case 替代长链 if-elif-else（Python 3.10+）
适用于：需要模式匹配（解构元组、匹配类型、带守卫条件），且 Python 版本 ≥ 3.10。
性能影响：比 if-elif 略快（CPython 内部做了优化），但差距微小；主要优势是语义清晰、支持结构化匹配。
容易踩的坑：
-
match不会自动类型转换，"1"和1是不同 case -
case _必须放最后，否则前面的 case 永远不会触发 - 守卫条件（
if子句）里不能有赋值表达式（比如:=），会报SyntaxError - 匹配类实例时需显式定义
__match_args__，否则无法按位置解构
示例：
立即学习“Python免费学习笔记（深入）”；
match message:
case {"type": "auth", "user": str(name), "level": int(l)} if l > 0:
return f"Auth OK: {name} (level {l})"
case {"type": "error", "code": 404}:
return "Not found"
case {"type": "ping"}:
return "pong"
case _:
return "Malformed message"
什么时候不该用字典或 match？
当分支逻辑之间有依赖、需共享状态、或存在“提前退出”控制流（如中间要 return / raise / break）时，强行塞进字典或 match 反而增加理解成本。
典型场景包括：
- 权限校验链：检查 token → 检查 scope → 检查 IP 白名单 → 最后放行
- 解析嵌套 JSON：每层结构不同，需递归 + 类型判断 + 错误恢复
- 状态机迁移：当前状态 + 事件 → 新状态 + 副作用，涉及副作用顺序
这类问题更适合策略模式、责任链或有限状态机，而不是单纯替换语法。
真正难的从来不是选字典还是match，而是识别出哪些分支本就不该并列存在——比如把「参数校验」和「业务处理」混在同一段 if 链里，这种耦合不拆，换什么语法都只是粉饰。 
