外观模式在Go中体现为ServiceFacade结构体，通过组合子服务、统一封装调用与错误，降低调用方认知负担；NewService仅是工厂函数，不解决链路分散问题。
Go 语言没有传统面向对象的继承和抽象类，但外观模式（Facade Pattern）依然能用——关键不是“怎么模拟 Java 风格”，而是“如何用 Go 的组合与接口特性，真正减少调用方的认知负担”。
为什么 func NewService(...) 不是外观，而 type ServiceFacade 才是
很多人把封装初始化逻辑当成外观模式，其实不然。外观的核心是「统一入口 + 隐藏子系统复杂性」。比如你有一组独立的服务：UserService、OrderService、NotificationService，各自有自己的一套配置、依赖、错误处理；如果调用方每次都要手动 new、校验、传参、处理不同 error 类型，那它就还没被“外观化”。
-
NewService()只是工厂函数，不解决调用链路分散问题 - 真正的外观必须提供一个顶层结构体（如
ServiceFacade），把多个子服务作为字段内嵌或组合，并暴露极简方法（如facade.PlaceOrder()） - 该方法内部协调子服务调用顺序、共用上下文、统一封装错误（比如把
user.ErrNotFound和order.ErrInvalidQuantity都转成facade.ErrBusiness）
如何避免外观变成“上帝对象”
外观容易越写越大，最后所有业务逻辑都塞进 ServiceFacade，违背单一职责。控制膨胀的关键是分层与边界意识：
- 外观层只做编排（orchestration），不做领域计算——金额校验、库存扣减等仍由对应子服务完成
- 子服务之间禁止直接引用对方的实现类型，只依赖接口（如
type UserRepo interface { GetByID(context.Context, int) (*User, error) }） - 外观的构造函数接受接口而非具体类型：
func NewServiceFacade(u UserRepo, o OrderRepo, n Notifier) *ServiceFacade，便于测试和替换 - 如果某功能明显属于垂直业务线（如“退款流程”），不要硬塞进通用外观，可另建
RefundOrchestrator，再由外观组合它
context.Context 必须贯穿外观方法，否则超时和取消会失效
外观方法看似只是胶水，但它是调用链的起点。一旦某个子服务没接收 context.Context，整个流程就失去超时控制能力。常见疏漏点：
立即学习“go语言免费学习笔记（深入）”；
- 外观方法签名漏掉
ctx context.Context，导致后续无法传递 deadline - 子服务方法支持
ctx，但外观里调用时传了context.Background()或未带 cancel - 并发调用多个子服务时，没用
ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)统一约束 - 错误返回时没检查
errors.Is(err, context.Canceled)或context.DeadlineExceeded，导致上层无法区分是业务失败还是链路中断
正确示例：
func (f *ServiceFacade) PlaceOrder(ctx context.Context, req *PlaceOrderReq) (*PlaceOrderResp, error) {
ctx, cancel := context.WithTimeout(ctx, 8*time.Second)
defer cancel()
user, err := f.userSvc.GetByID(ctx, req.UserID)
if err != nil {
return nil, err // 自动携带 context 错误
}
orderID, err := f.orderSvc.Create(ctx, user, req.Items)
if err != nil {
return nil, err
}
_ = f.notifier.SendOrderConfirmed(ctx, orderID) // fire-and-forget，但仍需 ctx 控制生命周期
return &PlaceOrderResp{OrderID: orderID}, nil
}
接口粒度决定外观是否真“简”
外观简化效果好不好，不取决于方法数量少，而取决于调用方是否需要理解中间状态。例如：
- 暴露
facade.GetUser(ctx, id)和facade.GetOrder(ctx, id)是“假简化”——调用方仍要分别处理用户不存在、订单未找到等逻辑 - 更优是按用例建接口：
type OrderPlacement interface { Place(ctx context.Context, input Input) (Output, error) }，让外观只暴露这个接口，隐藏所有子服务交互细节 - 甚至可以为前端 API 层定制外观：
type APIService interface { CreateOrderWithAuth(ctx context.Context, token string, req *json.RawMessage) error }，连身份解析都收进来
外观不是越薄越好，也不是越厚越好；它该厚在适配层（auth、log、metric、trace 注入），薄在业务逻辑——这部分永远留给子服务。
