在 Python 代码中，布尔值非常常见。
is_active = True
has_permission = False
debug = True
这些写法本身没有问题。布尔值适合表达状态、判断条件或配置开关。
但有一类布尔值值得警惕：作为函数参数，用来控制函数内部的不同行为路径。
例如：
def export_report(data, include_header: bool):
if include_header:
# 导出带表头的报表
...
else:
# 导出不带表头的报表
...
这种写法看起来简单直接，但随着业务演进，它往往会成为代码复杂度增长的起点。
本文讨论一个更可维护的设计原则：
不要在 Python 中滥用布尔标志：用策略对象替代行为开关
一、什么是 Boolean Flag？
所谓 Boolean Flag，通常是指函数参数中的布尔值，用来控制函数内部采用哪一种执行路径。
例如：
def send_email(user, urgent: bool):
if urgent:
send_with_high_priority(user)
else:
send_normal(user)
调用处可能是这样：
send_email(user, True)
问题来了：True 是什么意思？
如果不跳转到函数定义，调用者很难立刻知道这个布尔值代表“紧急邮件”“启用重试”“跳过校验”，还是其他行为。
即使使用关键字参数，可读性有所提升：
send_email(user, urgent=True)
但本质问题仍然存在：一个函数正在根据布尔参数执行两种不同职责。
二、Boolean Flag 的主要问题
1. 调用处语义不清晰
下面这段代码并不友好：
generate_invoice(order, True)
True 表示什么？是否含税？是否发送邮件？是否生成 PDF？是否覆盖已有文件？
相比之下，下面的调用更清楚：
generate_invoice(order, TaxIncludedPolicy())
或者：
generate_invoice(order, SendEmailAfterGenerated())
好的代码应该尽量让调用处自己说明意图，而不是要求读者频繁跳转到函数定义。
2. 函数内部职责变多
布尔参数通常意味着函数内部有条件分支：
def save_user(user, validate: bool):
if validate:
validate_user(user)
persist_user(user)
一开始这似乎没什么问题。
但随着需求增加，函数很容易变成这样：
def save_user(user, validate: bool, notify: bool, audit: bool):
if validate:
validate_user(user)
persist_user(user)
if notify:
send_notification(user)
if audit:
write_audit_log(user)
此时函数已经不再只是“保存用户”，它同时负责校验、持久化、通知和审计。
这违反了单一职责原则，也让测试组合数量迅速增加。
三个布尔参数会产生多少种行为组合？
2 × 2 × 2 = 8
如果有四个布尔参数，就是 16 种组合。
这就是 Boolean Flag 最危险的地方：它会悄悄制造行为组合爆炸。
3. 扩展能力差
假设现在有一个导出函数：
def export_report(data, include_header: bool):
if include_header:
...
else:
...
后来业务提出新需求：支持 Markdown 表头、国际化表头、自定义字段名。
你可能会继续加参数：
def export_report(
data,
include_header: bool,
markdown: bool,
localized: bool,
):
...
或者把布尔值改成枚举：
def export_report(data, header_type: str):
if header_type == "none":
...
elif header_type == "plain":
...
elif header_type == "markdown":
...
elif header_type == "localized":
...
这比布尔值稍好，但函数仍然知道太多具体实现细节。
每增加一种导出规则，都要修改原函数。久而久之，核心流程会被各种分支污染。
三、什么是 Policy？
Policy 可以理解为“策略”“规则”或“行为方案”。
它的核心思想是：
把会变化的行为从主流程中抽离出来，封装成独立的对象或函数，再由调用方传入。
例如原来的写法是：
def export_report(data, include_header: bool):
output = ""
if include_header:
output += "name,age\n"
for row in data:
output += f"{row.name},{row.age}\n"
return output
改成 Policy 之后：
class HeaderPolicy:
def render(self) -> str:
return "name,age\n"
class NoHeaderPolicy:
def render(self) -> str:
return ""
def export_report(data, header_policy):
output = header_policy.render()
for row in data:
output += f"{row.name},{row.age}\n"
return output
调用处变成：
export_report(data, HeaderPolicy())
export_report(data, NoHeaderPolicy())
此时 export_report 不再关心“是否包含表头”，也不关心“表头怎么生成”。
它只关心一件事：导出报表。
表头规则则交给不同的 Policy 实现。
四、使用函数作为 Policy
在 Python 中，并不一定非要使用类。由于函数是一等公民，很多场景下直接传函数会更简单。
例如：
def strict_validate(user):
if not user.email:
raise ValueError("email is required")
def skip_validate(user):
pass
def save_user(user, validation_policy):
validation_policy(user)
persist_user(user)
调用：
save_user(user, strict_validate)
save_user(user, skip_validate)
这比下面的写法更清晰：
save_user(user, validate=True)
save_user(user, validate=False)
因为 strict_validate 和 skip_validate 都明确表达了行为意图。
五、使用 Protocol 约束 Policy 接口
在更复杂的项目中，可以使用 typing.Protocol 来定义 Policy 的接口。
from typing import Protocol
class ValidationPolicy(Protocol):
def validate(self, user) -> None:
...
class StrictValidationPolicy:
def validate(self, user) -> None:
if not user.email:
raise ValueError("email is required")
class NoValidationPolicy:
def validate(self, user) -> None:
pass
def save_user(user, validation_policy: ValidationPolicy) -> None:
validation_policy.validate(user)
persist_user(user)
这样做的好处是：
- 调用方知道需要传入什么样的对象；
- 类型检查工具可以帮助发现错误；
- 代码结构更适合大型项目；
- Policy 可以拥有自己的状态和依赖。
例如：
class UniqueEmailValidationPolicy:
def __init__(self, user_repository):
self.user_repository = user_repository
def validate(self, user) -> None:
if self.user_repository.exists_by_email(user.email):
raise ValueError("email already exists")
这类逻辑如果继续塞进 save_user，函数会迅速变得臃肿。
六、一个更真实的例子：订单折扣
先看一个使用布尔参数的版本：
def calculate_price(order, apply_discount: bool):
total = sum(item.price for item in order.items)
if apply_discount:
total *= 0.9
return total
现在需求变化了：
- 普通用户无折扣；
- 会员用户 9 折；
- VIP 用户 8 折；
- 节假日额外优惠；
- 新用户首单优惠。
如果继续使用布尔值，很快就不够用了：
def calculate_price(
order,
is_member: bool,
is_vip: bool,
is_holiday: bool,
is_first_order: bool,
):
...
更好的方式是引入 Discount Policy：
from typing import Protocol
class DiscountPolicy(Protocol):
def apply(self, total: float) -> float:
...
class NoDiscountPolicy:
def apply(self, total: float) -> float:
return total
class MemberDiscountPolicy:
def apply(self, total: float) -> float:
return total * 0.9
class VipDiscountPolicy:
def apply(self, total: float) -> float:
return total * 0.8
def calculate_price(order, discount_policy: DiscountPolicy) -> float:
total = sum(item.price for item in order.items)
return discount_policy.apply(total)
调用处：
calculate_price(order, NoDiscountPolicy())
calculate_price(order, MemberDiscountPolicy())
calculate_price(order, VipDiscountPolicy())
如果以后要新增节假日优惠，只需要新增一个 Policy：
class HolidayDiscountPolicy:
def apply(self, total: float) -> float:
return total * 0.85
核心函数 calculate_price 不需要修改。
这就是 Policy 的优势：对扩展开放，对修改关闭。
七、Policy 也可以组合
Policy 的另一个优势是可以组合。
例如一个订单既享受会员折扣，又享受节假日折扣：
class CompositeDiscountPolicy:
def __init__(self, policies):
self.policies = policies
def apply(self, total: float) -> float:
for policy in self.policies:
total = policy.apply(total)
return total
调用：
discount_policy = CompositeDiscountPolicy([
MemberDiscountPolicy(),
HolidayDiscountPolicy(),
])
calculate_price(order, discount_policy)
相比多个布尔参数，这种方式更容易表达复杂业务规则。
布尔参数只能回答“是”或“否”，而 Policy 可以表达“如何做”。
八、什么时候 Boolean 是合理的？
并不是所有布尔值都应该被替换掉。
下面这些布尔值是合理的：
user.is_active
order.is_paid
feature_enabled
has_permission
它们描述的是状态，而不是选择一套复杂行为。
一般来说，可以用下面这个标准判断：
如果布尔值是在描述事实或状态，使用 bool 是合理的。
如果布尔值是在选择行为或算法，考虑使用 Policy。
例如：
if user.is_active:
...
这没问题，因为 is_active 是用户状态。
但下面这种就值得警惕：
process_payment(order, async_mode=True)
async_mode=True 很可能意味着完全不同的执行策略。
可以考虑改成：
process_payment(order, AsyncPaymentPolicy())
或者：
process_payment(order, payment_policy=AsyncPaymentPolicy())
九、什么时候不应该引入 Policy？
Policy 不是银弹。
如果逻辑非常简单，而且几乎不会变化，引入 Policy 可能会显得过度设计。
例如：
def log(message, debug: bool = False):
if debug:
print(f"[DEBUG] {message}")
else:
print(message)
如果这是一个很小的脚本，这样写完全可以接受。
但是，如果你发现某个布尔参数满足以下条件，就应该考虑重构：
- 它控制了明显不同的业务行为；
- 函数内部因为它出现了较大的
if/else分支； - 未来很可能会出现第三种、第四种行为；
- 测试用例开始围绕
True和False分别编写； - 调用处的
True/False不具备自解释能力； - 多个布尔参数开始同时出现在一个函数签名里。
尤其是下面这种函数签名，通常是明显的坏味道：
def create_user(
user,
validate=True,
send_email=True,
write_audit_log=False,
dry_run=False,
):
...
这类函数往往已经承担了太多职责。
十、从 Boolean Flag 重构到 Policy 的步骤
可以按照以下步骤逐步重构。
第一步：识别布尔参数控制的行为
例如：
def save_user(user, validate: bool):
if validate:
validate_user(user)
persist_user(user)
这里 validate 控制的是“是否执行校验行为”。
第二步：提取行为接口
可以先使用函数：
def strict_validate(user):
validate_user(user)
def no_validate(user):
pass
第三步：修改主函数依赖抽象行为
def save_user(user, validation_policy):
validation_policy(user)
persist_user(user)
第四步：修改调用处
原来：
save_user(user, validate=True)
save_user(user, validate=False)
改成：
save_user(user, strict_validate)
save_user(user, no_validate)
第五步：当逻辑变复杂时，再升级为类
class StrictValidationPolicy:
def validate(self, user):
validate_user(user)
class NoValidationPolicy:
def validate(self, user):
pass
def save_user(user, validation_policy):
validation_policy.validate(user)
persist_user(user)
这是一种渐进式重构方式，不需要一开始就设计复杂的类层次结构。
十一、Policy 与 Strategy Pattern 的关系
从设计模式角度看，Policy 本质上非常接近 Strategy Pattern。
Strategy Pattern 的核心思想是：定义一系列算法，把它们封装起来，并且使它们可以相互替换。
在 Python 中，实现 Strategy 不一定要像 Java 那样创建大量接口和类。Python 的函数、闭包、对象、Protocol 都可以作为策略。
例如，函数式写法：
def calculate_price(order, discount_func):
total = sum(item.price for item in order.items)
return discount_func(total)
类写法：
class DiscountPolicy:
def apply(self, total):
...
Protocol 写法：
class DiscountPolicy(Protocol):
def apply(self, total: float) -> float:
...
选择哪一种形式，取决于业务复杂度。
简单策略可以用函数。
复杂策略可以用对象。
需要类型约束时可以用 Protocol。
十二、总结
“不要在 Python 中滥用布尔标志：用策略对象替代行为开关” 并不是说 Python 代码中不能使用布尔值。
真正要避免的是：用布尔参数来控制函数内部的多种业务行为。
布尔参数看似简单，但它会带来几个问题：
- 调用处语义不清晰；
- 函数职责变多；
- 条件分支增加；
- 行为组合爆炸；
- 扩展能力变差；
- 测试复杂度上升。
相比之下，Policy 通过把可变行为抽离出来，可以让代码更加清晰、可测试、可扩展。
可以用一句话概括：
当 bool 描述状态时，它是合适的；当 bool 选择行为时，它往往应该被 Policy 取代。
在日常 Python 开发中，不需要为了每一个布尔参数都引入 Policy。但当你看到函数签名里出现多个 True / False，或者一个函数内部因为布尔参数出现明显的分支逻辑时，就应该停下来思考：
这个参数到底是在描述状态，还是在选择行为？
如果是后者，那么 Policy 很可能是更好的设计。