Basic Apple先声明一下：这不是一篇讲"背出23个模式类图"的文章。设计模式在Python里，很多时候不是"套用类图"，而是"理解封装变化的思路，然后用Python的方式轻量表达"。网上不少资料把Java的Gof写法原封不动搬到Python，结果代码又长又绕，看完只会让人更懵。这篇文章我尽量按照自己真实写代码的习惯来写：先把每个模式解决的核心问题讲透，再给在Python里最自然的实现方式，最后补一些实战中的取舍和注意事项。
1. 为什么在Python里聊设计模式，总有人先吵起来
在Python社区里，"设计模式"一直是个容易引战的话题。一部分人觉得Python是动态语言，很多模式的实现被语言内置特性替代了，根本不用刻意去套；另一部分人把Java系的设计模式奉为圭臬，写什么都先画类图。两边都有道理，但都不全对。
主张"Python不需要设计模式"的人，理由其实成立：Python有鸭子类型、一等函数、装饰器、上下文管理器、迭代器协议这些特性，GoF书里不少模式的代码量确实可以被大幅压缩，甚至直接消失——比如迭代器模式，Python的for循环天然就是迭代器；策略模式用一个函数参数就能搞定。但这不意味着设计模式的思想没用了。你依然会遇到"系统里某个变化点将来可能要扩展"的设计决策，你依然需要面对"多个算法可以互换""对象创建逻辑不该散落各处""对象间通知关系容易写成一团乱麻"这类问题。
另一方的问题在于：把Java的样板代码硬搬到Python，会写出非常"反Python"的代码。比如Java经典的单例写法是私有构造函数加静态方法，Python里根本不需要这样搞；Java的观察者模式要定义接口、维护订阅者列表，Python里写个装饰器、用弱引用保存回调就能解决一半问题。生搬硬套的结果是：代码类多、文件多、理解成本高，但功能没有任何增强，同事看了想打人。
我的态度比较实际：设计模式本质上是一套"沟通词汇"和"设计经验库"。它们不是模板代码，而是一组"在什么场景下，怎么封装变化"的参考答案。带着这套思路去写Python，你会自然地发现：哪些模式可以直接简化、哪些模式要换个形态、哪些模式真的一行都不用写。这篇文章就是想把这套"Python化的设计模式用法"串起来讲清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Python实现设计模式前必懂的语言特性
很多教程上来就直接摆单例、工厂、观察者的类图，然后贴代码。但Python是动态类型、基于协议的语言，不先搞懂几个底层机制，看代码会一直隔着一层。我先花几百字把后面所有例子都会用到的基础捋一遍。
2.1 鸭子类型：接口不再是interface
Java里定义接口要靠interface关键字，然后implements。Python里没有独立的接口语法，但这不是缺陷。Python的"协议"是隐式的：只要一个对象有__iter__方法，它就是可迭代的；有__enter__和__exit__，就能进with语句；有__call__，就可以像函数一样调用。
这个特性对设计模式影响巨大。适配器模式在Java里要写一个类去实现目标接口，在Python里经常什么都不用做。只要新对象的方法名和用法跟旧对象一致，它天然就是兼容的。后面讲适配器的时候，我会专门用例子说明这种差异。
2.2 一等函数与闭包：很多"类"可以被函数替代
Python里函数是头等公民，可以赋值给变量、放进列表、当参数传递、作为返回值。这意味着策略模式、命令模式、模板方法模式里那种"抽象类加子类实现"的写法，可以直接简化为"传一个函数进去"。
闭包配合默认参数，还能实现类似"对象状态"的效果。虽然Python里写类并不贵，但当一个角色的核心只有一个方法时，用函数比用类更简洁、更贴近函数式编程的思维方式。这个选择不是"谁对谁错"，而是要看你后续是否还要给这个角色附加其他状态和行为。
2.3 装饰器、生成器和上下文管理器
这三个语法特性分别是几个模式的"Python形态"：
- 装饰器（
@decorator）就是装饰器模式在语法层面的直接支持，后面专门讲。 - 生成器函数用
yield实现了惰性求值，这本质上是迭代器模式的高级形态，Python的for循环就是对迭代器协议的封装。 - 上下文管理器（
with）是"固定流程前后收尾"这个思想的语法化，在资源管理场景替代了模板方法模式的一部分职责。
理解这些之后，再看设计模式就会有一个变化：不再把模式当"类图模板"，而是把模式当"藏在语法背后的思想"。下一个层面的问题是，这些思想在什么场景下需要用Python代码显式表达出来。
2.4 元类、__new__与__init__：对象创建的底层入口
Python里一切皆对象，类也是对象。创建类的类是元类（默认是type），创建实例时先走__new__再走__init__。单例模式、工厂模式的"钩子"位置就在这些方法里。
用元类拦截类创建可以做很多事：自动注册子类、统一添加方法、实现单例约束。但元类是把双刃剑：阅读成本高、调试困难，我通常建议能不用就不用，只用它处理跨多个类的横切逻辑，别为了炫技引入。
2.5 模块天然是单例
Python的模块机制有个常被忽略的特性：模块只会被导入一次，后续import拿到的是同一个对象。这个特性直接让"模块级单例"成为Python里最简单也最Pythonic的单例方案，连类都不用写。
上面这些特性捋完之后，后面讲每个模式就能直接点出"这个模式在Python里的正解"是什么了。
3. 创建型模式：从"new对象"到"让对象自己冒出来"
创建型模式解决的核心问题，是不让业务代码直接依赖"具体类名"和"构造细节"，把"创建什么"和"怎么创建"从"使用"中解耦出来。在静态语言里，这一步通常需要抽象工厂、工厂方法、建造者等一整套类结构。在Python里，一半模式可以大大瘦身。
3.1 单例模式：Python里真的别再用那种写法了
先看反面教材。网上最常见的是这种Java直译版：
python复制class Singleton:
_instance = None
def __new__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
语法上讲，这段代码没问题。但从工程角度讲，它有几个隐患：
第一，多线程环境下需要加锁。虽然GIL让Python线程不能真正并行执行字节码，但在if cls._instance is None判断和super().__new__之间，线程仍然可能切换，导致创建出多个实例。要安全就得加threading.Lock，代码立刻变复杂。
第二，这个写法让单例类的子类出现时，所有子类共享父类的_instance，直接踩坑。
Python里我有三种推荐方案，按场景选：
方案一：模块级单例。最Pythonic，代码量趋近于零：
python复制# config.py
class AppConfig:
def __init__(self):
self.debug = False
self.retry_times = 3
app_config = AppConfig()
其他模块都from config import app_config，不管哪个模块导入，拿到的都是同一个对象。因为模块只会执行一次，这个对象天然全局唯一。除非你要在单测里反复重置状态、或者未来可能要多实例化，否则模块级单例完全够用。
方案二：__new__加锁的线程安全版本。确实需要类形式单例时可用：
python复制import threading
class DatabasePool:
_instance = None
_lock = threading.Lock()
def __new__(cls):
if cls._instance is None:
with cls._lock:
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
注意这里的双重检查锁（Double-Checked Locking），Python里GIL不能保证构造原子性，所以锁还不能省。这个版本好在不支持子类各自单例，但坏在锁是全局的，高频调用会有轻微性能损耗。
方案三：元类单例。当你有多个类都需要单例约束时，与其每个类复制一遍__new__，不如写一个元类统一管理：
python复制class SingletonMeta(type):
_instances = {}
def __call__(cls, *args, **kwargs):
if cls not in cls._instances:
cls._instances[cls] = super().__call__(*args, **kwargs)
return cls._instances[cls]
class AppConfig(metaclass=SingletonMeta):
pass
元类方案好在"一处写、处处用"，而且_instances是按类名来区分的，不同单例类之间不串数据。代价是理解了元类才能看懂。我用元类单例的场景一般是框架级代码，比如整个项目的配置管理器、日志处理器、连接池这类基础设施。
不过说实话，写业务代码时我越来越少主动用单例了。因为单例本质上就是全局可变状态，会让模块间耦合变高、测试难以隔离。现在更常见的做法是用依赖注入容器去管理生命周期：容器保证"这个对象全局只有一份"即可，业务代码不需要知道它是不是单例。设计模式的归宿是"约束藏在容器里"，而不是"每个类自己实现单例"。
3.2 工厂模式：从一堆if-else里把创建逻辑解放出来
工厂模式解决的问题，是"调用方不知道或不希望知道具体应该创建哪个类"。
不写工厂的时候，业务代码长这样：
python复制def send_notification(user, channel):
if channel == "email":
sender = EmailSender(user.email)
elif channel == "sms":
sender = SmsSender(user.phone)
elif channel == "wechat":
sender = WechatSender(user.openid)
else:
raise ValueError(f"Unknown channel: {channel}")
sender.send()
这段代码的问题不是if-else本身，而是：每增加一种通知渠道，就要改一次send_notification函数，这违反了开闭原则——对扩展开放、对修改关闭。更好的做法是把"根据渠道创建sender"这件事抽出来，让新增渠道时不用动老代码。
Python里最简单的工厂，其实就是一个函数加一个字典：
python复制class EmailSender:
def __init__(self, address):
self.address = address
def send(self, message):
print(f"email to {self.address}: {message}")
class SmsSender:
def __init__(self, phone):
self.phone = phone
def send(self, message):
print(f"sms to {self.phone}: {message}")
def create_sender(channel, user):
factories = {
"email": lambda u: EmailSender(u.email),
"sms": lambda u: SmsSender(u.phone),
"wechat": lambda u: WechatSender(u.openid),
}
sender_factory = factories.get(channel)
if sender_factory is None:
raise ValueError(f"Unknown channel: {channel}")
return sender_factory(user)
这种"注册表工厂"比一堆if-elif清晰得多，也更容易扩展。新增渠道时，你只需要创建一个新类，然后往factories字典里注册一项，send_notification完全不用动。如果factories这个注册表本身会随项目变动，还可以把它提取成模块级常量，甚至写成类属性，让子类自己覆盖注册表。
再往上一层，如果工厂本身也要支持不同产品族（比如你做跨平台UI，需要Windows风格和Mac风格的按钮、输入框），可以用抽象工厂。但我在Python里很少直接按GoF的抽象工厂模板写，而是用注册表加模块约定来替代：
python复制# ui_factory.py
class WindowsWidgetFactory:
def create_button(self):
return WindowsButton()
def create_textbox(self):
return WindowsTextbox()
class MacWidgetFactory:
def create_button(self):
return MacButton()
def create_textbox(self):
return MacTextbox()
def get_factory(platform):
factories = {"windows": WindowsWidgetFactory, "mac": MacWidgetFactory}
return factories[platform]()
这个代码仍然有"工厂类"，但是每个工厂只负责创建一组相关产品，这是抽象工厂的核心意图。动态语言里，你甚至可以不定义基类，只要每个工厂都有create_button和create_textbox方法，调用方就能正常工作——这就是鸭子类型的威力。
3.3 建造者模式：参数太多时，比**kwargs更体面的解法
建造者模式解决的不是"创建谁"，而是"一个复杂对象分步骤构建，步骤之间可能有不同组合"。对于Python，最常见的触发条件是：构造函数参数太多，动辄七八个、十几个，调用方根本分不清每个参数什么意思。
有人会用**kwargs，但kwargs有个问题：参数名错误要运行时才暴露，IDE也补不全提示。dataclass加默认值能解决一部分问题，但构建过程如果有必填顺序要求、或者同一套原料要构建出不同形态，建造者模式依然好用。下面用构建一份HTTP请求配置来举例：
python复制from dataclasses import dataclass, field
from typing import Optional
@dataclass
class RequestConfig:
url: str
method: str = "GET"
headers: dict = field(default_factory=dict)
params: dict = field(default_factory=dict)
body: Optional[bytes] = None
timeout: float = 10.0
retries: int = 0
class RequestConfigBuilder:
def __init__(self):
self._config = RequestConfig(url="")
def set_url(self, url: str):
self._config.url = url
return self
def set_method(self, method: str):
self._config.method = method
return self
def add_header(self, key: str, value: str):
self._config.headers[key] = value
return self
def set_body(self, body: bytes):
self._config.body = body
return self
def set_timeout(self, timeout: float):
self._config.timeout = timeout
return self
def set_retries(self, retries: int):
self._config.retries = retries
return self
def build(self) -> RequestConfig:
if not self._config.url:
raise ValueError("url is required")
return self._config
使用的时候是这样链式调用的：
python复制config = (
RequestConfigBuilder()
.set_url("https://api.example.com/data")
.set_method("POST")
.add_header("Content-Type", "application/json")
.set_body(b'{"key": "value"}')
.set_timeout(5.0)
.set_retries(3)
.build()
)
这种写法的好处是：每个步骤方法名即文档，IDE能提示完整方法列表；build()里可以统一做字段校验；构建过程可以复用，比如你定义一个默认builder，然后在不同业务里微调。缺点是代码量大，如果对象本身很简单、参数很少，就别硬上建造者，那属于过度设计。
4. 结构型模式：Python里那些悄悄隐形的结构魔法
结构型模式处理的是"对象之间的关系和组合方式"，目的是让类与类之间的结构更清晰、更容易扩展。这一组模式在Python里有个共同特点——很多关系不用显式建模，因为动态语言本身已经足够灵活。
4.1 适配器模式：鸭子类型直接消解了大半适配需求
适配器模式的经典场景是：新老接口不兼容，但又不想改老代码，于是写一个适配类把新接口转换为老接口。Java里要写class NewApiAdapter implements OldApi，然后逐方法委托。Python里这种场景经常被鸭子类型直接消化掉。
举个实际例子。假设项目里原本有一个WeatherService类：
python复制class WeatherService:
def get_temperature(self, city: str) -> float:
# ... 原逻辑
return 26.5
业务方有个函数：
python复制def print_temperature(service, city: str):
temp = service.get_temperature(city)
print(f"{city} temperature: {temp}°C")
后来公司换了一家新的天气数据源，新SDK的API完全不同：
python复制class NewWeatherSDK:
def fetch_celsius(self, city_name: str) -> float:
# ... 新逻辑
return 27.0
在Java里你需要写适配器。但在Python里，你只需要让新SDK类加一个同名的get_temperature方法：
python复制def adapt_weather_sdk(sdk: NewWeatherSDK):
def get_temperature(city: str) -> float:
return sdk.fetch_celsius(city)
sdk.get_temperature = get_temperature # 动态添加方法
return sdk
sdk = NewWeatherSDK()
sdk = adapt_weather_sdk(sdk)
print_temperature(sdk, "Shanghai")
这属于"猴子补丁式适配"，生产环境我用得少，原因是不易维护。更稳妥的写法是写一个薄薄的包装类：
python复制class NewWeatherSDKAdapter:
def __init__(self, sdk: NewWeatherSDK):
self._sdk = sdk
def get_temperature(self, city: str) -> float:
return self._sdk.fetch_celsius(city)
adapter = NewWeatherSDKAdapter(NewWeatherSDK())
print_temperature(adapter, "Shanghai")
包装类的好处是显式、可测试、职责清晰。但不管哪种方案，本质上都依赖Python的鸭子类型——你根本不需要声明"implements WeatherService"，只要方法存在、行为一致就行。这也提醒我们：在Python里设计接口时，不用提前搞一整套抽象基类，先让调用方直接使用，等真出现多个实现需要约束协议时，再用abc.ABC或typing.Protocol不迟。
4.2 装饰器模式：你早就用过的原生语法
装饰器模式的目标，是在不修改原对象代码的前提下，给对象动态增加职责。GoF里用类组合实现，Java里经常配合注解，Python就干脆把它做成了语法——@decorator。
最常见的例子之一是给函数加日志、加缓存、加重试。比如一个"重试装饰器"：
python复制import functools
import time
from typing import Callable, Type
def retry(max_retries: int = 3, delay: float = 0.5,
exceptions: tuple = (Exception,)):
def decorator(func: Callable) -> Callable:
@functools.wraps(func)
def wrapper(*args, **kwargs):
for attempt in range(max_retries + 1):
try:
return func(*args, **kwargs)
except exceptions as e:
if attempt == max_retries:
raise
time.sleep(delay)
return None
return wrapper
return decorator
@retry(max_retries=5, delay=1.0, exceptions=(ConnectionError, TimeoutError))
def fetch_data_from_api():
# ...
pass
这里装饰器就是装饰器模式的一个特化应用。但用的时候要注意几个坑：装饰器会改变原函数的元信息，必须用functools.wraps把__name__、__doc__等属性拷贝过去，否则很多调试工具和文档生成器会出问题；装饰器在导入时执行，注意别在装饰器里放耗时初始化逻辑。
还有一种经常被忽略的情况：装饰器模式在Python里也可以装饰类。比如要给一个类增加"单例约束"或"方法调用日志"，可以利用类装饰器：
python复制import functools
def log_calls(cls):
for name, method in vars(cls).items():
if callable(method) and not name.startswith("__"):
@functools.wraps(method)
def wrapper(*args, **kwargs):
print(f"Calling {name}")
return method(*args, **kwargs)
setattr(cls, name, wrapper)
return cls
@log_calls
class PaymentService:
def pay(self, amount: float):
print(f"paying {amount}")
不过这类"给类所有方法加日志"的操作，我在真实项目里更推荐用AOP工具或者直接在装饰器工厂里做，类装饰器适合小范围内聚类的横切逻辑增强。
4.3 外观模式与代理模式：边界封装的两个层次
外观模式（Facade）解决的是"子系统太复杂，客户端只需要简单入口"的问题。这个概念在Python里最典型的应用就是把一堆内部模块封装成一个简洁的公开API。
一个可观测性组件就能说明问题：底层有日志收集、指标上报、追踪链路三个子系统，每个系统都有自己的会话管理和初始化方法。如果你在业务代码里逐个初始化，任何一个环节变化都要改动多处。外观模式的做法是提供一个门面类：
python复制class TelemetryFacade:
def __init__(self):
self._logger = LogCollector()
self._metrics = MetricsReporter()
self._tracer = TraceExporter()
def start(self):
self._logger.initialize()
self._metrics.initialize()
self._tracer.initialize()
def shutdown(self):
self._tracer.flush()
self._metrics.flush()
self._logger.shutdown()
业务代码只需要telemetry = TelemetryFacade()，然后telemetry.start()。
代理模式和外观模式容易混淆。区别在于代理控制的通常是一个真实主题，服务于访问控制、延迟初始化、远程调用等；外观则是对多个子系统做聚合门面。Python里最常见的代理是"虚拟代理"——对象创建开销很大，真正要用的时候才初始化。下面用lazy property实现一个：
python复制class LazyProperty:
def __init__(self, func):
self._func = func
self._name = func.__name__
def __get__(self, instance, owner):
if instance is None:
return self
value = self._func(instance)
setattr(instance, self._name, value)
return value
class HeavyComponent:
@LazyProperty
def data_processor(self):
print("Creating heavy processor...")
return DataProcessor() # 假设初始化非常耗时
实现原理是利用了描述符协议。第一次访问属性时执行初始化，第二次直接命中实例上的同名属性，不再重复创建。这个写法在ORM框架里也大量使用，但要注意它不适合可变属性场景——如果后来有人给实例的data_processor重新赋值，就会删除原来的惰性加载行为。
4.4 组合模式：树形结构中的"单个和整体一致对待"
组合模式解决的是树形结构场景：希望把叶子节点和容器节点一致对待，客户端不需要区分"这个对象是文件夹还是文件"。文件系统、组织架构、菜单权限树都是典型场景。
Python实现组合模式时，可以用一个类加类型标记判断，也可以用两个类加公共接口。我见过不少代码用"一个类一个children字段，空列表表示叶子"，这种方式最省事，但会丢失叶子语义。我比较推荐用两个轻量类加一个抽象基类：
python复制from abc import ABC, abstractmethod
class Component(ABC):
@abstractmethod
def get_size(self) -> int:
pass
class File(Component):
def __init__(self, size: int):
self._size = size
def get_size(self) -> int:
return self._size
class Directory(Component):
def __init__(self):
self._children: list[Component] = []
def add(self, child: Component):
self._children.append(child)
def remove(self, child: Component):
self._children.remove(child)
def get_size(self) -> int:
return sum(child.get_size() for child in self._children)
客户端只需要处理Component类型，根本不用关心加File还是Directory。get_size递归累加，目录和文件口径一致。在真实项目里，组合模式和访问者模式经常搭配出现（比如对一棵权限树做不同遍历处理），但Python里用生成器遍历会更自然，不一定需要引入Visitor那种偏重的结构。
5. 行为型模式：把算法、调度与通知的设计思路理清楚
行为型模式是我日常写代码用到最多的一类，它们关注的是"对象之间的职责分配和通信方式"。行为型模式里藏着大量Python特色实现，且很多用函数、生成器、上下文管理器替换了传统类结构。
5.1 策略模式：一个函数参数解决的事
策略模式的核心思想是：定义一组算法，把它们逐个封装起来，并且使它们可以相互替换。Java里通常是"接口加实现类"的结构，Python里最简单就是函数。
拿一个实际的运费计算场景来讲。订单会根据不同物流方式计算运费，每个渠道计费规则不同：
python复制def standard_shipping_cost(order):
return 5.0 + order.weight * 1.2
def express_shipping_cost(order):
return 15.0 + order.weight * 2.5
def international_shipping_cost(order):
return 30.0 + order.weight * 5.0 + order.customs_fee
shipping_strategies = {
"standard": standard_shipping_cost,
"express": express_shipping_cost,
"international": international_shipping_cost,
}
def calculate_shipping(order, strategy_name: str):
strategy = shipping_strategies[strategy_name]
return strategy(order)
这段代码没有类、没有接口，但策略模式的目的完全达成了：每种算法独立成函数，可以单独测试；新增策略就是新增一个函数然后注册到字典里。
那什么时候需要把策略写成一个类？如果策略本身有状态或者有多个方法需要复用，比如策略需要从配置中心读取自己的参数、策略有自己的预热接口，那时用类更合适。Python不必为了模式而模式，函数优先、类候补，是我写策略模式的默认排序。
如果策略数量多，且未来添加策略时不想改动主注册表，可以配合functools.singledispatch或插件系统做自动注册。不过一般业务规模下，一个字典足够了，别过度设计。
5.2 观察者模式：从事件回调到弱引用陷阱
观察者模式是发布-订阅思想的一个具体化：当被观察对象状态变化时，自动通知所有依赖它的观察者。GUI按钮点击、消息总线、股票价格变动都是这个思路。
Python里最简单的观察者实现可以直接用列表保存回调函数：
python复制class NewsPublisher:
def __init__(self):
self._subscribers = []
def subscribe(self, callback):
self._subscribers.append(callback)
def unsubscribe(self, callback):
self._subscribers.remove(callback)
def publish(self, news):
for callback in list(self._subscribers):
callback(news)
使用：
python复制def user_a_notify(news):
print(f"User A received: {news}")
publisher = NewsPublisher()
publisher.subscribe(user_a_notify)
publisher.publish("Design patterns in Python released")
这个实现有个隐患藏在list(self._subscribers)里：如果某个观察者的回调在调用过程中又把新的订阅者加进来，直接遍历原列表可能会跳过或报错。用切片复制可以避免"迭代时修改列表"的问题。
更隐蔽的坑是内存泄漏：如果订阅者是一个对象绑定的方法（比如self.handle_notify），那这个对象会被列表引用着，对象就算不再使用也无法被垃圾回收。解决方式是用weakref保存弱引用：
python复制import weakref
class NewsPublisher:
def __init__(self):
self._subscribers = []
def subscribe(self, callback):
# 方法对象不能直接weakref，需要保存其绑定对象和函数名
if hasattr(callback, "__self__"):
self._subscribers.append(weakref.WeakMethod(callback))
else:
self._subscribers.append(weakref.ref(callback))
def publish(self, news):
dead = []
for ref in self._subscribers:
callback = ref()
if callback is None:
dead.append(ref)
else:
callback(news)
# 清理失效引用
for ref in dead:
self._subscribers.remove(ref)
这段代码略显繁琐，所以我个人在真实项目里更推荐直接用一个成熟的事件库，比如blinker。它的底层已经处理好了弱引用和线程安全问题，Python社区也大量使用。用blinker写观察者模式时核心代码量几乎为零：
python复制from blinker import Signal
news_signal = Signal()
@news_signal.connect
def user_a_notify(news):
print(f"User A received: {news}")
news_signal.send("Design patterns in Python released")
总结一下：观察者的思想在Python里无处不在，但生命周期管理才是真正需要关心的坑。如果在自己的项目里手写观察者，至少要为"弱引用"和"发消息期间订阅列表被修改"这两个场景兜底，否则线上环境迟早会因内存泄漏或RuntimeError给你颜色看。
5.3 模板方法模式：父类定框架，子类填细节
模板方法模式的思路是：在父类里定义算法的骨架，把某些步骤延迟到子类实现。你希望多个子类复用同一套主流程，但流程中的具体步骤各有差异。
Python里除了类继承，还有两种更轻量的替代：依赖注入函数、装饰器。不过遇到"流程固定但步骤多变且步骤很多"的情况，模板方法模式依然是最自然的表达。
举一个数据导入的例子。不同数据源的导入流程大致相同：连接源、读取数据、清洗转换、写入目标库、发通知。但每个环节的具体实现差异很大：
python复制from abc import ABC, abstractmethod
class DataImporter(ABC):
def import_data(self, source: str):
self.connect(source)
data = self.read_data(source)
cleaned = self.clean_data(data)
self.write_data(cleaned)
self.notify()
def connect(self, source: str):
# 默认实现
print(f"Connecting to {source}")
@abstractmethod
def read_data(self, source: str):
pass
def clean_data(self, data):
# 默认实现
return data
@abstractmethod
def write_data(self, data):
pass
def notify(self):
# 默认钩子，子类可覆盖
pass
class CsvImporter(DataImporter):
def read_data(self, source: str):
return ["csv row1", "csv row2"]
def write_data(self, data):
print(f"Writing {len(data)} rows to database")
class ApiImporter(DataImporter):
def read_data(self, source: str):
# 调用API并解析
return ["api record1", "api record2"]
def write_data(self, data):
print(f"Writing {len(data)} records to database")
父类的import_data就是骨架，子类只需要实现抽象方法，可选覆盖钩子方法。这个模式在Python里用抽象基类写很自然。实际项目中，我通常把"公共逻辑确定、变化点明确"的流程设计成模板方法，再配合类型提示和子类测试，会比每个类里复制粘贴主流程好维护得多。
如果嫌继承太重，也可以把可变步骤作为函数参数传入。比如：
python复制def import_data(reader, writer, source):
reader.connect(source)
data = reader.read(source)
writer.write(data)
这里用鸭子类型约定reader和writer都要有什么方法，不必硬继承抽象基类。怎么选？如果多个导入器之间有大量公共步骤和默认实现要复用，模板方法更合适；如果公共部分很少、变化点密集，函数参数方案更轻、更灵活。
5.4 命令模式：把操作变成可传递的对象
命令模式将"请求"封装成对象，从而支持参数化调用、排队、撤销、重做等操作。编辑器里的Ctrl+Z、事务系统中的操作队列，都是命令模式的典型应用。
Python的一个特殊之处在于，函数本来就可以当作命令对象传递，所以很多命令模式场景直接用函数或functools.partial就能解决。但如果你需要支持撤销，或者命令里要附带完整上下文，一个轻量类会更顺手：
python复制from dataclasses import dataclass
class Command(ABC):
@abstractmethod
def execute(self):
pass
@abstractmethod
def undo(self):
pass
@dataclass
class InsertTextCommand(Command):
document: "Document"
position: int
text: str
def execute(self):
self.document.insert(self.position, self.text)
def undo(self):
self.document.delete(self.position, len(self.text))
为什么用类而不用函数？因为undo需要记录执行时的具体位置和状态，一个包含"业务数据"和"反向操作"的类对象，明显比闭包更清晰。这也说明：用不用类，标准是"这个角色需不需要多个方法且需要保存状态"，而不是"这个模式书上用什么结构我就用什么"。
5.5 状态模式：用状态机管理业务流转
状态模式解决的问题是：对象的行为随内部状态变化而变化，传统写法是多个if/elif判断状态位，状态多了代码立刻爆炸。状态模式把每种状态下行为拆分到单独类中，对象把请求委托给当前状态对象。
订单状态流转是个经典例子：新订单、已付款、已发货、已完成、已取消，不同状态下能执行的操作不同。用状态模式写：
python复制class OrderContext:
def __init__(self):
self.state = NewOrderState()
def pay(self):
self.state.pay(self)
def ship(self):
self.state.ship(self)
def complete(self):
self.state.complete(self)
class State(ABC):
@abstractmethod
def pay(self, context: OrderContext):
pass
@abstractmethod
def ship(self, context: OrderContext):
pass
@abstractmethod
def complete(self, context: OrderContext):
pass
class NewOrderState(State):
def pay(self, context):
print("Order paid")
context.state = PaidState()
def ship(self, context):
raise ValueError("cannot ship unpaid order")
def complete(self, context):
raise ValueError("cannot complete unpaid order")
class PaidState(State):
def pay(self, context):
raise ValueError("order already paid")
def ship(self, context):
print("Order shipped")
context.state = ShippedState()
def complete(self, context):
raise ValueError("cannot complete unshipped order")
class ShippedState(State):
def pay(self, context):
raise ValueError("cannot pay shipped order")
def ship(self, context):
raise ValueError("order already shipped")
def complete(self, context):
print("Order completed")
context.state = CompletedState()
这个模式代码量比较大，但换来的收益是每个状态独立成类，状态流转在源码里能直观看到，非法操作能在对应状态下捕获。不过一定要提醒：如果你的状态数量少、流转简单，只有一两个状态位，硬上状态模式反而增加阅读负担。可以用enum加状态流转表替代，不少Python项目里用transitions这类专门的状态机库管理更复杂的状态流转。
5.6 责任链模式：中间件式的请求传递
责任链模式的核心是：多个处理器依次尝试处理请求，链上的某节点决定自己处理还是传给下一个。在Web框架里，中间件机制正是责任链模式的最佳体现，比如Flask的before_request钩子、Django的中间件列表。
Python里的责任链有两种常见实现方式。第一种是每个处理器持有下一个处理器的引用，形成链表；第二种是把处理器放进一个列表，循环遍历。列表方式更Pythonic、更容易定义顺序：
python复制class BaseHandler:
def __init__(self):
self._next = None
def set_next(self, handler: "BaseHandler") -> "BaseHandler":
self._next = handler
return handler
def handle(self, request):
if self._next:
return self._next.handle(request)
return None
class AuthHandler(BaseHandler):
def handle(self, request):
if not request.get("token"):
return "auth failed"
return super().handle(request)
class RateLimitHandler(BaseHandler):
def handle(self, request):
if request.get("user") == "blocked":
return "rate limited"
return super().handle(request)
class BusinessHandler(BaseHandler):
def handle(self, request):
return "business handled"
# 构建责任链
handler = AuthHandler()
handler.set_next(RateLimitHandler()).set_next(BusinessHandler())
result = handler.handle({"token": "valid", "user": "bob"})
这段代码的问题在于链的构建固定。如果你希望"责任链"由外部配置动态决定顺序，直接维护一个列表更灵活：
python复制def auth_handler(request, next_handler):
if not request.get("token"):
return "auth failed"
return next_handler(request)
def rate_limit_handler(request, next_handler):
if request.get("user") == "blocked":
return "rate limited"
return next_handler(request)
def business_handler(request, next_handler):
return "business handled"
middlewares = [auth_handler, rate_limit_handler, business_handler]
def dispatch(request):
def runner(index, req):
if index >= len(middlewares):
return None
return middlewares[index](req, lambda r: runner(index + 1, r))
return runner(0, request)
后面这种"中间件函数列表"的写法在真实框架里更常见，也更容易做动态插拔。责任链模式的核心不在于是链表还是列表，而在于"每个节点只决定自己能不能处理，不能则交棒"。
6. 模式之间的搭配：一个插件化消息处理系统的实战组合
前面把常用模式拆开讲了一遍。但真实项目里很少只用一个模式，这里我串一个综合场景，把前面涉及的好几个模式组合起来，看看它们怎么互相配合。
假设要做一个可扩展的消息处理系统：接收不同类型的消息，做校验、去重、格式化，最终推送通知。需求方明确说，未来要不断增加新的消息类型和新的通知渠道，而且要支持动态启停某些插件。
第一层，消息类型用工厂加注册表管理。每种消息一个解析类，解析类负责把原始JSON变成结构化消息对象。增加新消息类型时，只需要注册新类，不用改主逻辑。
第二层，处理流程是固定骨架——校验、清理、推送——但不同消息类型细节不同，这里用模板方法模式定主流程。
第三层，通知渠道是典型的策略模式，push函数作为策略注册进字典，未来加短信、邮件、站内信都只是增加一个实现。
第四层，消息处理的状态记录用状态模式管理，已接收、处理中、处理完成、处理失败这几个状态决定哪些操作可执行。
这些模式组合起来，类会变多，代码看起来也更"重"，但每个类都足够小、足够单一。模块之间通过注册表或抽象基类解耦，新同学接到"增加一个某某消息类型"的需求时，只需要照着已有的类模仿，然后在注册表里加一行，再也不用在几百行的if-elif里翻找。
这里要强调一个组合模式的边界：模式是用来管理变化点的，如果系统本身没有那么多变化点，纯粹堆模式反而会制造无意义的抽象层。多少变化点算多？我的经验值大致是：一个维度如果预测会稳定在3种以内，直接用条件判断写清楚就好；如果明确知道上限很高、插入频繁，再考虑策略池或插件化。
7. 依赖注入：比"创建型模式全家桶"更常用的解耦方案
依赖注入严格来说不算GoF里的设计模式，但在现代Python工程里的重要性，比很多经典模式都要高。它的思想非常朴素：一个类需要什么依赖，不要自己在内部new出来，而是让外部创建好再传进来。
先看不推荐的写法：
python复制class OrderService:
def __init__(self):
self._payment = PaymentGateway() # 直接依赖具体实现
self._logger = FileLogger() # 直接依赖具体实现
def process_order(self, order):
self._logger.log("start")
self._payment.charge(order.amount)
self._logger.log("done")
这段代码的问题在于OrderService的三个职责耦合在一个构造函数里：创建订单服务的人，无法替换PaymentGateway为假支付、无法把日志切到消息队列。测试时要么真的连支付网关，要么用猴子补丁，都很痛苦。
依赖注入重构后：
python复制class OrderService:
def __init__(self, payment, logger):
self._payment = payment
self._logger = logger
def process_order(self, order):
self._logger.log("start")
self._payment.charge(order.amount)
self._logger.log("done")
创建服务的责任交给了上层容器或合成根。测试时可以注入假对象：
python复制class FakePayment:
def charge(self, amount):
print(f"Fake charge {amount}")
class FakeLogger:
def log(self, message):
print(f"Fake log {message}")
service = OrderService(FakePayment(), FakeLogger())
这种手动注入在小型项目里够用。如果项目依赖关系复杂，手动组装会变得繁琐，可以考虑用dependency-injector这类容器库，用声明式方式管理"对象生命周期"和"依赖图谱"。
依赖注入和工厂模式之间的关系是：工厂负责"怎么创建"，依赖注入负责"把创建好的依赖送到需要的人手里"。两者可以配合使用——工厂创建实例，依赖注入容器管理实例的装配和生命周期。实际工程中，我至少做到"构造函数里不出现new"或"构造函数里不直接初始化具体依赖"这一层，代码的可测试性就会有很大改观。
8. Python中实现设计模式的核心原则与过度设计警示
把前面那么多模式过一遍后，可以拎出几条真正重要的原则。这些原则比记住某个模式的类图有用得多，也更能帮你判断什么场景下该用什么。
第一，面向接口编程，但Python的接口是协议不是类。不需要每个类都挂一个抽象基类。当一个角色有多个实现、且这些实现要被替换时，定义抽象基类或Protocol是有用的；如果只有一个实现，抽象基类就是多余的。
第二，优先组合而非继承。GoF全书都在推崇组合优先。Python里组合的写法非常自然，把依赖作为构造参数传进去就是最简单的组合。继承只适合"真正的is-a"关系，且父类大部分逻辑可以被复用的情况。
第三，封装变化点。写代码的时候留意一下，哪些需求将来最可能变？数据库换了、通知渠道增加了、第三方服务参数调整了。把稳定不变的流程骨架从易变细节中拆出来，就是模板方法、策略、工厂这些模式共同的底层逻辑。
第四，不要为了"将来可能扩展"而过度设计。尤努斯的名言在工程里同样适用："现在我们不做YAGNI的事。"很多扩展需求其实永远不会来。正确的时机是什么？是当你真的出现第二个实现、第二个消息类型、第二个通知渠道时，再顺手重构出抽象。第一次就老老实实写具体代码，一点也不丢人。
我还想专门说一下"抽象泄露"和"模式误用"造成的认知负担。新人最容易犯的错，是看到一个框架代码觉得很高大上，于是模仿它建了一堆基类和工厂，但业务逻辑根本不复杂，结果维护成本比收益大得多。面试的时候我会问"这些抽象解决了什么问题"，答不上来的基本就是在堆模式。
在设计模式这个话题上，我的个人经验是：理解它们的关键不是背类图，而是先意识到"变化点在哪里"，再从模式库里挑选能"封装这个变化点"的成熟方案。如果你发现一个设计方案无法用一两句话说清楚它保护了哪个变化点，那这个设计大概率是过度设计。
9. Python设计模式的学习路径与素养建议
写到这里，给出一个可以照着做的学习路径建议。这个路径不是"看书目录"，而是我自己踩过弯路的总结，尽量帮后来者少走一些。
第一步，先掌握Python语言本身那套特性：鸭子类型、装饰器、生成器、上下文管理器、描述符、元类。网上有大量资料，但一定要亲手写。设计模式的很多"Python正解"是建立在这些语言机制之上的，语言特性不熟，模式实现会始终带着Java影子。
第二步，把GoF的23个模式过一遍，但先别急着看Python实现。先读它的意图和适用场景。每读一个，问自己：这个"意图"在我现在的Python项目里已经遇到过吗？当时是怎么解决的？这个过程能帮你建立"模式意图"与"真实痛点"的连接，而不是背空壳。
第三步，再去看Python具体实现，对比自己第一步想到的解法。重点观察"Python版实现比Java版少了哪些类""少了之后的代码少了什么约束"。
第四步，回到自己的项目做一次"模式巡检"。翻出你最想重构的那块代码，识别出里面的变化点，然后尝试用适合的Python模式重写一版。不一定要改线上代码，本地写一个对比测试也行。这阶段收获会非常大。
第五步，持续积累的场景是阅读知名开源库源码。比如requests库、click库、pip、celery，它们都有大量设计模式应用。读开源代码时重点关注抽象边界，多问一句"这个地方为什么用一个类而不是一个函数"。
对不同基础的读者，我的建议也有差别。Python语法刚入门不久的人，建议先花至少一两个星期把语言基础打牢，特别是类和面向对象编程要熟练，再上手设计模式；如果已经写过一段时间业务代码，对"需求变更导致代码反复被打补丁"已经有体感，那直接读这篇文章里推荐的几个最常用的模式场景，边看边动手做个小项目，效果最好。基础偏弱也没关系，模式本身不是特别难，难的是不动手。
另外，Python生态里还有很多跟设计模式紧密相关的工程实践话题，比如类型注解与抽象基类的配合、插件系统的自动发现机制、事件驱动的微服务架构。这些话题本身可以展开写很多，这篇文章先在思路上点一下，后续可以单独成篇。
Python里实践设计模式，本质上掌握的是一套"建立清晰边界、封装变化、保障可替代性"的工程方法论。它不要求你把23个模式都刻在脑子里，而是要求你在遇到问题时，能知道"这里存在一个成熟解法可以参考"。它是工程经验的高度浓缩，而不是必须遵守的宗教教条。