Python中多重组合条件判断的高效替代方案

首先先处理最容易被忽略的性能损耗点：你当前的写法如果condition1/condition2/condition3是需要计算的表达式（比如函数调用、数据遍历、逻辑运算结果），会在多个分支中被重复求值，这才是拉低执行速度的核心原因——纯布尔判断本身的开销可以忽略不计。
最基础的优化就是先把所有条件的结果缓存到变量，只计算一次：

c1 = condition1
c2 = condition2
c3 = condition3

这一步做完，哪怕保留原来的if-elif结构，性能已经能提升一大截，尤其是条件本身计算耗时的场景。

你同事提到的字典映射实现类switch逻辑，完全可以用来处理组合条件，核心思路是把多个布尔条件的结果组合成可哈希的元组作为键，直接映射到对应分支的处理逻辑，查找过程是O(1)时间复杂度，没有层层分支判断的额外开销，也不会因为分支顺序写错导致逻辑被提前拦截。
首先我们可以先把你现有分支按从上到下的优先级，拆解出所有3个布尔条件共8种组合对应的命中分支：

• 分支1（c1 and c2）：命中(1,1,0)、(1,1,1)两种组合，和c3无关
• 分支2（(c1 or c2) and not c3）：排除分支1已经命中的(1,1,0)，剩下(1,0,0)、(0,1,0)两种组合
• 分支3（(c3 and c2) and not c1）：仅命中(0,1,1)
• 分支4（c1 or c2）：排除前面所有命中的组合，剩下(1,0,1)
• 默认分支（else）：命中剩下的(0,0,0)、(0,0,1)

基于这个拆解，字典映射的实现代码如下，建议把每个分支的执行逻辑封装成独立函数，避免代码冗余：

# 各分支处理逻辑
def branch1():
    # 放原第一个if块的代码
    pass

def branch2():
    # 放原第一个elif块的代码
    pass

def branch3():
    # 放原第二个elif块的代码
    pass

def branch4():
    # 放原第三个elif块的代码
    pass

def branch_default():
    # 放原else块的代码
    pass

# 构建条件组合到处理函数的映射表
condition_dispatch = {
    (True, True, True): branch1,
    (True, True, False): branch1,
    (True, False, False): branch2,
    (False, True, False): branch2,
    (False, True, True): branch3,
    (True, False, True): branch4,
}

# 执行逻辑
c1, c2, c3 = condition1, condition2, condition3
handler = condition_dispatch.get((c1, c2, c3), branch_default)
handler()

如果你的项目用的是Python 3.10及以上版本，内置的match-case模式匹配写起来会更简洁，不需要提前构建映射表，性能和字典方案基本一致，还支持通配符简化组合写法：

c1, c2, c3 = condition1, condition2, condition3
match (c1, c2, c3):
    case (True, True, _): # 通配符表示不关心c3的值
        # 分支1逻辑
        pass
    case (True, False, False) | (False, True, False): # | 匹配多组合
        # 分支2逻辑
        pass
    case (False, True, True):
        # 分支3逻辑
        pass
    case (True, False, True):
        # 分支4逻辑
        pass
    case _:
        # 默认分支逻辑
        pass

方案选择建议 #

• 如果分支逻辑简单、后续几乎不会改动，缓存条件结果之后保留原if-elif写法即可，可读性足够，性能也没有问题
• 如果分支较多、后续迭代需要频繁调整逻辑，优先选字典映射或者match-case方案，可维护性更高，不容易出顺序判断的bug
• 如果条件数量超过4个，布尔组合会指数增长（4个条件有16种组合，5个有32种），这时候硬编码所有组合的维护成本太高，更适合用责任链模式实现

最后说性能：不存在绝对更快的写法，所有性能损耗基本都来自条件本身的重复计算，只要保证所有条件只求值一次，几种写法的性能差异在绝大多数业务场景下都可以忽略。

内容的提问来源于stack exchange，提问作者Remian-Feral