外观模式在Go中是通过struct+interface+显式组合实现的接口封装策略，用于隐藏子系统复杂性，需依赖注入、错误映射、业务语义命名，并避免过度封装。
外观模式在 Go 中不是语言特性，而是接口封装策略
Go 没有 class、继承或“外观模式”标准实现，所谓“外观模式”在 Go 里本质是用 struct + interface + 显式组合来隐藏子系统复杂性。它不靠设计模式标签驱动，而靠开发者主动收敛调用入口。
典型场景：你有一组分散的模块——auth.Service、payment.Client、notification.Sender，外部每次调用都要导入三四个包、初始化多个实例、处理各自错误。这时你就该考虑加一层薄薄的门面。
- 不要把门面做成单例全局变量（比如
var Facade = NewFacade()），这会破坏可测试性和依赖显性化 - 门面结构体应只持有接口字段，而非具体实现类型，例如：
auth auth.Service而非auth *auth.JWTService - 门面方法应返回业务语义明确的结果，而不是把底层错误原样透传；需做错误映射，比如把
payment.ErrInsufficientBalance转为ErrPaymentFailed
如何定义一个可测试的门面结构体
关键不是“怎么写”，而是“怎么让它的依赖能被替换”。Go 的依赖注入靠构造函数参数传递，不是反射或容器。
type OrderFacade struct {
auth auth.Service
payment payment.Client
notify notification.Sender
}
func NewOrderFacade(
a auth.Service,
p payment.Client,
n notification.Sender,
) *OrderFacade {
return &OrderFacade{
auth: a,
payment: p,
notify: n,
}
}
这样写之后，单元测试就能传入 mock 实现：
立即学习“go语言免费学习笔记（深入）”；
- 用
gomock或手写mockAuth实现auth.Service接口 - 避免在
NewOrderFacade内部 new 出具体类型（如&auth.JWTService{...}） - 如果某子系统暂时没抽象出接口，先自己定义一个最小契约接口，比直接依赖具体类型更可持续
门面方法命名要反映业务动作，而非拼接子系统名
别写 facade.AuthAndChargeAndNotify() 这种方法。它暴露了内部流程，且一旦流程变更（比如加风控校验），方法签名或语义就得改。
应该按用户/调用方视角命名：
-
facade.PlaceOrder(ctx, req)—— 隐藏鉴权、扣款、发通知等步骤 -
facade.RefundOrder(ctx, orderID)—— 内部可能调payment.Refund()+notify.Send() - 每个方法只做一件事，哪怕背后调了 4 个子系统；职责不清的门面会快速腐化成“上帝对象”
注意：若某个操作存在多种路径（如支付支持余额+微信+支付宝），门面不应在内部 if-else 分支选择实现，而应把策略交给调用方传入，或通过组合不同门面实例来隔离。
什么时候不该加外观？警惕过度封装
外观模式的价值在于降低**高频、跨模块、语义聚合型**调用的认知成本。但它不是银弹。
- 两个模块只在一处耦合（比如仅在 CLI 命令里一起用），直接调用更清晰
- 子系统本身已足够简单（如只有一个函数
cache.Get(key)），再包一层facade.GetCache(key)属于噪声 - 团队对模块边界已有共识、文档完善、错误码统一，此时外观可能只是增加间接层
- 性能敏感路径（如高频日志上报），额外 struct 字段访问和接口动态调度有微小开销，需实测确认是否可接受
最常被忽略的一点：门面一旦建立，就承担了向后兼容责任。后续修改接口或行为时，必须考虑所有已使用该门面的调用方——它不再是内部封装，而成了隐性 API 边界。
