Python条件优化技巧：告别多层if判断

应优先用字典映射替代多层if-elif-else链，适用于离散可哈希条件；用in替代多个==判断；用any()/all()替代冗长逻辑表达式；避免嵌套过深，及时重构职责与状态模型。

用字典映射替代多层 if-elif-else 链

当条件是离散、有限且可哈希的值（如字符串、数字、枚举），直接查表比逐个判断快得多，也更易维护。常见于状态码处理、路由分发、配置分支等场景。

容易踩的坑：dict.get() 返回 None 时未设默认值，或忘了处理键不存在的情况；映射值是函数时忘记加括号调用。

• 优先用 dict 而非 match-case（Python 3.10+）——后者编译期检查强，但动态键不支持
• 若分支逻辑复杂，把每个分支封装成独立函数，字典中存函数对象而非内联表达式
• 避免在字典里存带副作用的 lambda，调试困难且无法单元测试

status_handlers = {
    "pending": handle_pending,
    "approved": handle_approved,
    "rejected": handle_rejected,
}
handler = status_handlers.get(status, handle_unknown)
result = handler(data)

用 in 替代多个 == 判断

写 if x == "a" or x == "b" or x == "c" 不仅啰嗦，还容易漏写或拼错变量名。Python 的 in 操作符对小集合（<10项）性能几乎无损，可读性提升明显。

注意：in 对 list 是 O(n)，对 set 或 frozenset 才是 O(1)。若判断高频且集合较大（如上百项），务必用 set。

• 常量集合建议定义为模块级 frozenset，避免每次执行都重建
• 不要用 in 判断浮点数是否“等于某几个值”，精度问题会导致意外失败
• 字符串前缀/子串匹配不能用 in 简单替换，得用 .startswith() 或正则

VALID_ROLES = frozenset(["admin", "editor", "viewer"])
if user_role in VALID_ROLES:
    grant_access(user_role)

提前返回（Early Return）减少嵌套层级

多层 if 嵌套最典型的问题不是性能，而是可读性和出错概率——缩进深、逻辑分支交织、else 块难以定位。用守卫子句（guard clauses）把异常或边界情况提前处理并 return 或 raise，主逻辑自然落在顶层缩进。

关键区别：这不是“去掉 else”，而是让正常流程线性展开，错误路径不拖累主干。

• 参数校验、空值检查、权限不足、资源未就绪等，都适合提前返回
• 避免在提前返回前做重操作（如数据库写入、文件打开），否则可能造成资源泄漏
• 函数有多个退出点时，确保所有路径都覆盖了必要的清理逻辑（可用 try/finally）

def process_order(order):
    if not order:
        return {"error": "order is None"}
    if order.status != "draft":
        return {"error": "only draft orders allowed"}
    if not order.items:
        return {"error": "no items found"}
    # 主逻辑从这里开始，缩进为 0
    return execute_payment(order)

用 any() / all() 简化布尔组合条件

写 if a > 0 and b > 0 and c > 0 或 if x == "A" or x == "B" or x == "C" 是信号：该用内置高阶函数了。它们语义清晰、短路求值、支持生成器表达式，比手写循环更 Pythonic。

性能上，any() 在首个真值即停，all() 在首个假值即停，和原生 and/or 行为一致，但结构更统一。

• 别把列表推导式传给 any()——先生成完整列表再判断，浪费内存；改用生成器表达式 (x > 0 for x in numbers)
• any([]) 返回 False，all([]) 返回 True，空集合的逻辑需确认是否符合业务预期
• 嵌套过深的条件（如 any(all(...))）要警惕，可能说明数据结构或职责需要重构

if any(item.price < 0 for item in order.items):
    raise ValueError("Negative price detected")
if all(item.in_stock for item in order.items):
    ship_order(order)

复杂条件往往不是靠“换写法”解决的，而是暴露了职责过载或状态建模不当。优化前先问一句：这个判断，本该属于谁？