应优先用字典映射替代多层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 操作符对小集合（
注意：in 对 list 是 O(n)，对 set 或 frozenset 才是 O(1)。若判断高频且集合较大（如上百项），务必用 set。
立即学习“Python免费学习笔记（深入）”；
- 常量集合建议定义为模块级
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)复杂条件往往不是靠“换写法”解决的，而是暴露了职责过载或状态建模不当。优化前先问一句：这个判断，本该属于谁？
