Go中Facade模式用私有字段结构体+依赖注入实现，拆分为小方法便于测试与维护，通过传入不同依赖实现环境隔离，不承担事务管理与领域规则。
Go 里怎么写一个靠谱的外观（Facade）结构
外观模式在 Go 里不是靠 interface 或抽象类实现的，而是靠「一个干净的结构体 + 一组封装好的方法」。它不追求设计模式教科书式复刻，只解决一件事：让调用方不用知道 database.DB、cache.RedisClient、mailer.SMTPClient 这些底层怎么拼起来的。
实操建议：
- 定义一个顶层结构体（比如
AppService），字段全是私有（小写开头），只暴露初始化函数和业务方法 - 所有依赖通过构造函数注入，别在方法里 new 实例——否则测试没法 mock，也藏不住变化点
- 方法名用动词开头（
SendWelcomeEmail、CreateUserWithProfile），别叫DoSomething这种模糊名
为什么不能把所有逻辑塞进一个 Facade 方法里
常见错误是写一个巨长的 ProcessOrder 方法，里面直接调 payment.Charge、inventory.Decrease、notify.SMS……看着省事，实际埋了三个坑：
- 无法单独测试某一步（比如只想验证短信模板是否正确，却得走完整流程）
- 一旦某个子系统改接口（比如
inventory.Decrease加了 context 参数），整个Facade都得动 - 并发场景下难控制粒度（比如库存扣减要加锁，但发邮件不需要，混在一起反而容易锁错范围）
正确做法是拆成小方法：facade.chargePayment()、facade.reserveInventory()，再由组合方法协调顺序和错误处理。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何让 Facade 支持不同环境（测试 / 开发 / 生产）
关键不是写 if-else 切换逻辑，而是靠依赖注入时传入不同的实现。比如：
// 测试用假实现
type MockMailer struct{}
func (m *MockMailer) Send(to string, body string) error { return nil }
<p>// 生产用真实 SMTP
type SMTPMailer struct{ client <em>smtp.Client }
func (s </em>SMTPMailer) Send(to string, body string) error { /<em> real send </em>/ }</p><p>// Facade 初始化时决定用哪个
func NewAppService(mailer Mailer, db <em>sql.DB, cache </em>redis.Client) *AppService {
return &AppService{mailer: mailer, db: db, cache: cache}
}
这样单元测试直接传 &MockMailer{}，完全绕过网络和外部依赖。别在 Facade 内部判断 os.Getenv("ENV") == "test" ——那会让行为不可预测，也违反单一职责。
Facade 和 service 层的区别在哪
很多人混淆这两者，结果把 UserService 写成外观，又把 OrderFacade 写成业务逻辑聚合器。记住一个判断标准：
-
UserService应该只管用户相关操作（增删改查、密码重置），不碰订单或通知 -
OrderFacade可以调userRepo.GetByID、paymentSvc.Charge、emailSvc.Send，但它自己不实现任何领域规则（比如“优惠券只能用一次”这种校验，得交给couponSvc.Validate） - Facade 的方法签名应该贴近最终业务动作（
CreateOrder(req OrderRequest)），而不是技术动作（RunTransaction(...)）
最常被忽略的一点：Facade 不负责事务边界管理。它可能调用多个带事务的方法，但要不要开启新事务、回滚到哪一层，得由上层（比如 HTTP handler 或 job worker）决定。硬塞进去，反而让复用性和测试性变差。
