Facade 是一种通过结构体封装多依赖调用、提供简洁接口的设计模式，Go 中无需类继承即可实现，核心是降低调用方认知负担，关键在于统一超时、错误处理与依赖注入，避免沦为上帝对象。
Facade 是什么，为什么 Go 里不用类也能实现
Go 没有类和继承，但外观模式（Facade）本质不是靠继承实现的，而是靠「封装一组操作到一个干净接口」。你不需要抽象基类或接口继承链，只需要一个结构体 + 一组方法，把底层多个包、多个函数的调用逻辑收拢进来。关键不在“模式名字”，而在“是否真的减少了调用方的认知负担”。
常见错误现象：main.go 里反复 import database/sql、redis.Client、http.Client，再各自初始化、传参、错误检查——这就是该上 Facade 的信号。
- 使用场景：微服务中某个业务入口（如
CreateOrder）需协调库存、支付、通知三个子系统 - Facade 结构体本身不持有业务逻辑，只做参数分发和错误聚合
- 不要在 Facade 里做重试、熔断、日志埋点——那是中间件或单独组件的事
怎么写一个真正有用的 Facade 结构体
别一上来就定义 type OrderFacade struct 然后堆方法。先想清楚：调用方最常传什么？返回什么？哪些错误必须暴露？哪些可以内部吞掉或统一转成 ErrServiceUnavailable？
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 字段只存依赖项指针，比如
db *sql.DB、cache *redis.Client，**不存 context 或 request ID**（这些应该由调用方传入） - 所有公开方法接收
context.Context，第一行就做ctx, cancel := context.WithTimeout(ctx, 5*time.Second)—— 超时控制必须在 Facade 层统一设，不能甩给下游 - 返回值统一为
(result, error)，避免混用error和自定义错误类型；若下游返回*json.UnmarshalTypeError，Facade 应转为更友好的ErrInvalidResponse
示例：
type PaymentFacade struct {
client *http.Client
timeout time.Duration
}
func (f *PaymentFacade) Charge(ctx context.Context, req ChargeRequest) (ChargeResponse, error) {
ctx, cancel := context.WithTimeout(ctx, f.timeout)
defer cancel()
// ... 构造 HTTP 请求、调用、解析
}
为什么 Facade 容易变成“上帝对象”
因为写着写着，发现“顺手加个缓存”“再加个幂等校验”“顺便记录下耗时”……最后这个结构体既初始化 DB 又起 goroutine 又打日志，测试起来要 mock 十几个东西。
容易踩的坑：
- 在 Facade 里直接 new 一个
redis.NewClient()—— 这会让单元测试无法注入 mock，正确做法是通过构造函数传入 - 把不同子系统的错误码全塞进一个
switch err.(type)分支里处理 —— 导致修改支付错误逻辑时，得翻通知模块的 error 定义 - 给 Facade 加了太多辅助方法（如
ValidateOrder()、BuildReceipt()），结果调用方反而绕过 Facade 直接调这些方法
性能影响：如果 Facade 在每次调用时都重新构建 HTTP header、拼接 URL 字符串、重复解析配置，会放大延迟。把这些提到初始化阶段，或用 sync.Pool 缓存可复用对象。
测试 Facade 时最该验证什么
不测它“能不能连 Redis”，而测它“在 Redis 返回超时错误时，是否返回预期的 ErrPaymentTimeout”。Facade 的测试核心是契约：输入确定，依赖行为确定，输出是否符合文档承诺。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用 interface 抽象下游依赖，比如定义
type PaymentClient interface { Charge(ctx context.Context, req ChargeRequest) (ChargeResponse, error) }，测试时直接传 mock 实现 - 重点覆盖错误传播路径：当库存服务返回
ErrOutOfStock，Facade 是否原样透出，还是包装成ErrOrderFailed并附带 trace ID？这个策略必须写进注释，且测试显式 assert - 避免在测试里 sleep 等待 goroutine —— Facade 方法应全部同步完成，异步动作（如发 MQ）应由调用方决定是否等待
容易被忽略的一点：Facade 的构造函数是否 panic？比如传入 nil 的 *sql.DB 时，应该立刻 panic 并提示 “db must not be nil”，而不是等到第一次 Charge() 才 panic。这点不写测试，上线后 debug 成本极高。
