Go外观模式适用于需统一屏蔽支付、风控、IoT等复杂子系统接口的场景，通过结构体封装依赖、接口注入、错误收敛实现解耦，避免沦为冗余包装器或横切逻辑容器。
什么时候该用 Go 外观模式（Facade）
外观模式在 Go 里不是语言特性，而是结构型设计模式的落地实践——它适合你已经有一堆分散、耦合、职责不清的包或函数，但对外只想暴露一个干净接口的场景。不是所有“封装”都叫外观模式，关键看是否在屏蔽子系统复杂性的同时统一入口。
典型适用业务场景
以下情况直接考虑加一层 facade 包或结构体：
- 支付网关整合：要同时调用
AlipayClient、WechatPayClient、UnionPaySDK，但上层服务只关心Pay(req *PaymentReq) (*PaymentResp, error) - 风控引擎聚合：需串联
RuleEngine、DeviceFingerprint、BlacklistChecker，但订单服务只调一次CheckRisk(orderID string) (bool, error) - IoT 设备管理：底层涉及
MqttPublisher、OTAUpdater、StatusReporter，但 Web API 只提供RestartDevice(deviceID string) error
Go 中实现外观模式的关键细节
Go 没有类继承，所以外观通常是一个结构体，持有各子系统实例，并提供组合后的方法。注意三点：
- 子系统依赖应通过接口注入，而非直接 import 具体实现（否则破坏解耦）；例如定义
type PaymentService interface { Pay(...) }，再让AlipayClient实现它 - 外观结构体本身不存业务状态，避免成为全局单例瓶颈；推荐每次调用新建或从池中获取（如
facade.NewPaymentFacade(alipay, wechat, union)） - 错误处理要收敛：子系统返回的
errors.Is(err, xxx)或自定义错误码，应在外观层转为统一错误类型（如ErrPaymentFailed），别把context.Canceled或sql.ErrNoRows直接透传出去
type PaymentFacade struct {
alipay PaymentService
wechat PaymentService
union PaymentService
logger *log.Logger
}
func (f *PaymentFacade) Pay(req *PaymentReq) (*PaymentResp, error) {
switch req.Channel {
case "alipay":
return f.alipay.Pay(req)
case "wechat":
return f.wechat.Pay(req)
default:
return nil, ErrUnsupportedChannel
}
}
容易被忽略的陷阱
外观模式最常被误用为“大杂烩包装器”，结果越包越重：
立即学习“go语言免费学习笔记（深入）”；
- 把日志、监控、重试、限流等横切逻辑塞进外观方法里——这些应该走中间件或装饰器，不是外观的职责
- 外观方法开始做参数校验、DB 查询、HTTP 调用——它只应编排已有子系统，不新增原子能力
- 为每个子系统方法都套一层同名转发（如
facade.GetOrder() → orderSvc.GetOrder()），没做任何抽象和简化，纯属冗余 - 多个外观互相依赖（A 依赖 B，B 又依赖 A），导致初始化循环或隐式耦合
真正有效的外观，是让调用方代码行数减少 50% 以上，且不再需要了解下游模块的初始化顺序、超时配置、重试策略。
