Facade 结构体不应盲目导出，是否导出取决于初始化方式：有外部依赖时应通过工厂函数（如 NewOrderService）返回；若无依赖且需导出，须提供带校验的构造函数，字段小写、仅通过方法暴露能力。
Facade 结构体该不该导出？
Go 里实现 Facade，核心是封装多个子系统接口，对外只暴露一个干净的入口。但别一上来就把 Facade 类型大写导出——它是否导出，取决于你是否允许调用方直接初始化它。
常见错误：定义了 type Facade struct{...}，又在包外 new 出来，结果子系统依赖（比如数据库连接、HTTP 客户端）全得由使用者传入，反而更麻烦。
- 如果 Facade 依赖具体实现（如
*sql.DB、*http.Client），建议用工厂函数返回，比如NewOrderService()，内部完成依赖组装 - 如果 Facade 只做纯逻辑编排、无外部依赖，可导出结构体，但务必提供带校验的构造函数，避免零值误用
- 导出结构体 + 导出字段 = 调用方可能绕过 Facade 直接操作子系统，违背模式本意；字段一律小写，仅通过方法暴露能力
方法命名要避开子系统原名，比如别叫 PayWithAlipay()
Facade 的价值不是“把三个支付方法列一遍”，而是抽象出业务语义。叫 ProcessPayment() 比 PayWithAlipay() 或 PayWithWechat() 更符合外观模式意图——使用者不该关心底层用了哪家支付，只关心“付款成功”这个结果。
容易踩的坑：方法名泄露实现细节后，一旦切换支付渠道，所有调用点都要改名，Facade 就白做了。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先用动宾短语表达业务动作：
PlaceOrder()、CancelSubscription()、VerifyUser() - 若需保留多渠道选择，用参数控制，而不是拆成多个方法：
PlaceOrder(&OrderRequest{PaymentMethod: "alipay"}) - 子系统错误要转换：把
alipay.ErrInvalidSign包装成ErrPaymentFailed，否则上层还得 import 支付 SDK
依赖注入时，接口比具体类型更安全
Facade 内部依赖的子系统，必须用接口而非具体类型声明。否则一换数据库驱动或 mock 测试，就得改 Facade 源码。
典型反例：db *sql.DB —— 这会让 Facade 和 database/sql 强绑定，没法替换成内存 mock 或其他 ORM。
- 定义清晰接口，如
type OrderRepository interface { Create(*Order) error }，Facade 只依赖这个 - 生产环境传入
&postgresRepo{db: realDB}，测试时传&mockOrderRepo{}，完全无感 - 别为了“省事”在 Facade 里 new 子系统实例（比如
redis.NewClient()），这会让单元测试无法控制边界
别在 Facade 里做重试、熔断、日志——那是中间件的事
外观模式只负责“简化调用”，不是兜底层。加重试逻辑看似方便，实则污染职责：下次要换重试策略，就得动 Facade；要加链路追踪，又得改它；最后 Facade 变成胶水代码集合。
真实场景中，这些横切关注点应该剥离到独立层，比如用装饰器包装 Facade 实例：
service := NewOrderService(db, payment) service = WithRetry(service, 3) service = WithTracing(service, tracer)
- Facade 方法保持简单：输入 → 编排子系统 → 输出，不处理超时、重试、监控埋点
- 错误返回统一用自定义 error 类型（如
ErrOrderNotFound），但不要在里面打日志——日志由调用方或 middleware 决定何时打、打多少 - 性能影响明显：在 Facade 里加延迟重试，会拖慢所有走这个入口的请求；而装饰器可按需启用
Facade 最容易被忽略的一点：它不解决分布式事务或最终一致性问题。别指望靠它把订单、库存、积分扣减变成原子操作——那得靠 Saga 或消息队列，Facade 只管把这几个步骤串起来调用而已。
