外观模式在Golang中通过接口抽象、结构体组合和导出控制实现，核心是隐藏子系统细节、暴露简洁契约；定义PaymentFacade接口声明高层行为，外观结构体内聚协调子系统调用并统一错误处理，辅以工厂函数和依赖接口提升可测性与灵活性。
外观模式（Facade Pattern）的核心是为复杂子系统提供一个统一、简洁的接口，Golang 中没有类和继承，但通过结构体组合、接口抽象和封装导出函数，完全可以优雅实现外观模式，关键在于“隐藏细节、暴露契约”。
定义清晰的外观接口
先设计一个高层接口，描述外部使用者真正关心的操作，不暴露子系统内部结构。比如构建一个支付服务外观：
- 定义 PaymentFacade 接口：包含
ProcessOrder(amount float64) error这类语义明确的方法 - 接口只声明行为，不涉及银行卡校验、库存扣减、通知发送等具体步骤
- 让调用方只依赖这个接口，后续可自由替换实现而不影响业务逻辑
组合子系统并封装实现
创建具体外观结构体，内部嵌入或持有多个子系统实例（如订单服务、风控服务、消息服务），并在其方法中协调它们：
- 用非导出字段（小写首字母）隐藏子系统，例如
orderService *OrderService -
ProcessOrder方法内按顺序调用：f.validate(amount)→f.reserveStock()→f.chargeCard()→f.notify() - 错误统一处理并转换为高层语义错误（如
ErrPaymentFailed），避免把数据库超时、网络错误等底层异常直接抛给上层
提供工厂函数简化初始化
Golang 习惯用函数替代构造器。导出一个 NewPaymentFacade() 函数，内部完成子系统实例化与依赖注入：
- 函数返回
PaymentFacade接口类型，而非具体结构体，利于 mock 和测试 - 可接受配置选项（如
WithTimeout(30*time.Second)）或依赖项（如传入已初始化的
*redis.Client） - 调用方只需一行代码：
facade := NewPaymentFacade(WithLogger(log.Default()))
配合接口隔离提升可测性
每个子系统也应定义自己的接口（如 CardProcessor, InventoryClient），外观结构体依赖这些接口而非具体实现：
- 测试时可用 fake 实现快速验证流程逻辑，无需启动真实 Redis 或调用第三方支付网关
- 例如 mock
CardProcessor.Charge()返回固定错误，验证外观是否正确透传或降级 - 接口即契约，既约束实现，也降低模块间耦合
基本上就这些。Golang 的外观模式不靠语法糖，而靠接口设计意识 + 组合思维 + 导出控制。重点不是“怎么写结构体”，而是“哪些不该让别人看到，哪些必须让人一眼看懂”。
