Facade模式在Go微服务中解决调用方对多个下游服务依赖分散的问题，通过组合+导出接口统一收口跨服务调用，降低认知负担与出错概率。
Facade模式在Go微服务中解决什么问题
它不是为了解耦接口和实现，而是为了收口调用方对多个下游服务或模块的依赖。当你发现一个业务函数里反复写 userSvc.GetUser()、orderSvc.GetOrdersByUID()、notifySvc.SendSMS() 这类跨包调用时，就该考虑加一层 Facade 了。
Go 没有抽象类或继承驱动的 Facade，它的实现本质是「组合+导出接口」：把底层依赖注入到结构体中，再统一暴露简洁的方法。关键不在“模式名称”，而在是否真的减少了调用方的认知负担和出错概率。
如何定义一个可测试、易替换的Facade接口
别直接暴露 struct，必须先定义 interface。否则单元测试时无法 mock，重构时也会卡住。
- 接口方法名要面向业务动作，比如
PlaceOrderWithUserCheck()，而不是CallUserAndOrderSvc() - 入参尽量用 value 类型（如
int64、string）或不可变 DTO（如type PlaceOrderReq struct{ UID int64; Items []Item }），避免传指针导致副作用难追踪 - 返回值优先用具体 error（如
*user.NotFoundError）而非泛化error，方便调用方做类型断言处理 - 接口定义放在调用方能 import 的位置（通常是 facade 包下），而不是被封装的服务包里
初始化Facade时依赖注入的常见陷阱
很多人会把 new 函数写成无参的 NewOrderFacade()，内部直接 new 各个 service 实例——这会让测试完全失控，也违反了依赖倒置。
- 必须显式接收依赖：比如
func NewOrderFacade(u user.Service, o order.Service, n notify.Service) *OrderFacade - 如果某依赖是可选的（如通知服务降级），不要用 nil 判断，而是提供带默认行为的 wrapper，例如
notify.NoopSender{} - 避免在 Facade 初始化时做 heavy init（如连接池预热），应延迟到首次调用时，或由上层统一管理生命周期
- 注意循环依赖：facade 包不能 import controller 或 handler 包，否则编译失败；所有依赖方向必须单向指向底层
Facade方法里要不要做重试、熔断、超时控制
要做，但只做“调用粒度”的控制，不做“业务逻辑重试”。比如 PlaceOrderWithUserCheck() 内部对 userSvc.GetUser() 设置 2s 超时 + 1 次重试是合理的；但对整个下单流程做重试就错了——那是上层事务或 saga 的事。
- 超时建议用
context.WithTimeout()透传，不要硬编码 time.Sleep - 熔断推荐用现成库（如
sony/gobreaker），状态存储独立于 Facade 实例，否则重启即失效 - 错误聚合要分层：底层 service 返回
user.ErrRateLimited，Facade 可转为facade.ErrUpstreamRateLimited，保持语义清晰 - 日志打点必须包含 traceID 和关键参数（如 UID、OrderID），否则线上排查时根本串不起链路
最常被忽略的一点：Facade 不是万能胶，它不该承担数据转换、缓存组装、权限校验等职责——那些应该由单独的 domain 层或 adapter 处理。越想让它“啥都干”，就越容易变成难以维护的上帝对象。
