Go中外观模式通过结构体组合封装子系统，提供简洁高层接口，隐藏实现细节与错误，支持依赖注入和场景化拆分，本质是聪明的组合与清晰契约。
在 Go 语言中，外观模式（Facade Pattern）不是靠继承或接口抽象来实现的，而是通过封装一组复杂子系统的操作，提供一个简洁、统一的高层接口。它不改变原有逻辑，只做“门面”——让调用方不用关心内部模块如何协作。
用结构体封装多个子系统
Go 没有传统面向对象的抽象类或多重继承，但恰好适合用组合方式实现外观模式。定义一个外观结构体，内嵌或持有各个子系统实例，再暴露少量方法把它们串起来。
- 子系统可以是独立的包（如
payment、notification、inventory），各自职责清晰 - 外观结构体不暴露子系统字段，只通过方法协调调用顺序和错误处理
- 例如下单流程：先扣库存 → 再发起支付 → 最后发通知，外观层统一控制流程和回滚逻辑
避免暴露底层细节，隐藏错误转换
调用方不该看到子系统返回的具体错误类型（比如 payment.ErrInsufficientBalance）。外观层应统一转为业务语义明确的错误，或包装成自定义错误类型。
- 用
fmt.Errorf("failed to place order: %w", err)包装底层错误，保留原始信息但不泄露实现 - 对常见失败场景做语义映射：支付超时 →
ErrOrderTimeout，库存不足 →ErrOutOfStock - 必要时在外观方法中做参数校验（如订单ID非空、金额大于0），提前拦截非法请求
支持可选配置与依赖注入
外观结构体应便于测试和替换依赖。推荐通过构造函数传入子系统实例，而非在内部直接初始化。
立即学习“go语言免费学习笔记（深入）”；
- 定义
NewOrderFacade(p PaymentService, n Notifier, i Inventory) *OrderFacade - 单元测试时可传入 mock 实现，验证流程是否按预期执行
- 生产环境用 DI 框架（如 wire 或 dig）自动组装，保持外观层轻量无副作用
不滥用：外观 ≠ 大杂烩
一个外观结构体只服务于一个明确的业务场景（如 “创建订单”、“用户注册”、“退款审核”）。不要把所有功能都塞进一个 Facade。
- 不同场景拆成不同外观：
OrderFacade、UserFacade、RefundFacade - 如果某个外观方法开始变长、分支多、难维护，说明它可能承担了太多职责，该拆分或引入策略/状态模式辅助
- 外观方法本身应尽量无状态、无业务规则判断——规则交给子系统或单独的服务层
基本上就这些。Go 的外观模式本质是“聪明的组合 + 清晰的契约”，不复杂但容易忽略接口边界设计。写好一个 Facade，能让上下游代码都更安心。
