外观模式的核心作用是屏蔽依赖关系而非封装逻辑，通过构造时注入并组合底层组件，使上层仅依赖单一窄接口，明确表达能力需求而非模块细节。
外观模式的核心作用不是封装逻辑，而是屏蔽依赖关系
外观模式（Facade）在 Python 中真正解决的问题，不是“把一堆函数包起来”，而是让调用方完全不知道背后有 requests、json、datetime、甚至多个微服务模块。它不改变原有逻辑，只切断上层代码和底层模块的直接 import 和调用链。
常见错误是把外观类写成工具函数集合，比如：
class APIClient:
def get_user(self): ...
def send_email(self): ...
def log_event(self): ...
这看似统一，但一旦 send_email 内部依赖了某个尚未初始化的 SMTP 连接对象，或 log_event 需要传入全局配置实例，调用方就又得操心初始化顺序和参数传递——耦合没降，反而更隐蔽。
正确做法是：外观类在 __init__ 中完成所有底层组件的构造与组装，并通过组合（composition）持有它们：
立即学习“Python免费学习笔记（深入）”；
class OrderServiceFacade:
def __init__(self, payment_client: PaymentClient, inventory_client: InventoryClient, notifier: Notifier):
self._payment = payment_client
self._inventory = inventory_client
self._notifier = notifier
这样上层只依赖 OrderServiceFacade 一个类，且它的构造参数明确表达了“需要什么能力”，而不是“需要哪些模块”。
避免把外观变成新上帝对象的三个信号
当你的外观类开始出现以下情况，说明它正在退化为反模式：
- 方法超过 7 个，且职责横跨数据获取、校验、缓存、日志、重试——这不是外观，是调度中心
- 某个方法内部直接 import 了本不该出现在该层的模块（如在外观里 import
sqlalchemy或celery） - 为了支持不同场景，开始加大量
if mode == "test"或use_cache=True这类开关参数
外观的本质是“窄接口、宽实现”。它对外暴露的每个方法，应该对应一个清晰的业务动作（如 place_order()），而不是技术动作（如 call_payment_api()）。如果业务动作本身开始变复杂，说明该拆分的是业务流程，而不是往外观里堆逻辑。
Python 中最常被忽略的初始化陷阱：循环依赖与延迟加载
外观类往往要协调多个已有模块，而这些模块之间可能存在隐式依赖。比如 InventoryClient 初始化时会读取配置，而配置又由 ConfigLoader 提供——但如果 ConfigLoader 又依赖 logging，而 logging 的 handler 初始化又调用了网络服务……这种链式初始化很容易在 __init__ 里触发失败。
解决方案不是把所有东西都改成 lazy 属性，而是分清“必须立即可用”和“按需加载”：
- 配置、连接池、基础客户端（如
httpx.AsyncClient）应在__init__中完成初始化 - 临时资源（如单次使用的数据库 session）、非关键 fallback 组件（如降级通知器），可用
@property+if not hasattr(self, '_xxx')延迟创建 - 绝对不要在
__init__中调用外部 API 或等待 I/O，那会让整个外观类不可测、不可缓存
例如，下面这段代码看着简洁，实则危险：
def __init__(self):
self.config = load_config() # 可能读文件或远程配置中心
self.db = create_engine(self.config['db_url']) # 同步阻塞
应改为显式传入已准备好的 config 和 db_engine，把初始化责任交还给容器或工厂函数。
测试外观类时，mock 的边界在哪
测试 OrderServiceFacade.place_order() 时，你不需要 mock PaymentClient.charge() 的返回值结构，但必须确保它被以正确的参数调用了一次。重点不是模拟行为，而是验证协作契约。
典型误操作：
- 对
InventoryClient.reserve()返回一个伪造的 dict，结果实际生产中它返回的是NamedTuple，导致外观里字段访问出错 - 没 mock
Notifier.send()，导致测试发真实邮件或钉钉消息 - mock 了太多底层方法，导致测试变成“检查 mock 被调用了几次”，而非“检查业务结果是否符合预期”
推荐方式是：只 mock 外观直接持有的依赖对象（即构造函数参数类型），并用 assert_called_with() 校验调用参数；对返回值，只 mock 其类型（如 Mock(spec=PaymentResult)），不伪造内容。这样既隔离外部依赖，又保留类型契约。
外观模式的价值不在代码行数减少，而在让“谁该知道什么”变得可推断。一旦你发现修改一个下游模块，必须同步改外观类里的三处调用逻辑，那问题大概率不在外观本身，而在底层模块的接口设计太细碎——这时候该重构的是那些模块，而不是给外观加更多胶水代码。
