go外观模式典型适用场景是封装松散耦合的子系统（如日志、缓存、数据库）以降低认知负担和耦合泄漏；应通过接口注入依赖、避免构造函数阻塞操作、方法名体现业务意图、统一错误包装，并用接口而非具体类型定义字段。
什么是 Go 外观模式的典型适用场景
当你需要封装一组松散耦合但协同工作的子系统（比如日志、缓存、数据库、http 客户端），又不想让业务代码直接依赖它们的具体实现时，外观模式就不是“可选”，而是必要。它不解决并发或泛型问题，只解决调用链路的**认知负担**和**耦合泄漏**。
如何用一个 Facade 结构体聚合多个依赖
关键不是写个空壳结构体，而是明确谁负责初始化、谁负责生命周期管理。常见错误是把 newredisClient()、newDB() 全塞进 Facade 构造函数里——这会导致测试难、启动慢、错误定位模糊。
- 让
Facade接收已构造好的依赖实例（推荐）：type OrderFacade struct { cache CacheClient db *sql.DB logger *zap.Logger } func NeworderFacade(cache CacheClient, db *sql.DB, logger *zap.Logger) *OrderFacade { return &OrderFacade{cache: cache, db: db, logger: logger} } - 避免在
NewXXX()中做阻塞操作（如连接池建立、配置加载）；这些应由上层完成后再注入 - 如果必须内部初始化，至少提供
Close()方法并文档注明资源归属
方法命名要反映业务意图，而非底层动作
外观方法名不能叫 CallCacheThenDB() 或 DoQueryWithRetry()——这是暴露实现细节。用户关心的是“查订单”“取消订单”，不是你用了 redis 还是 BoltDB。
- 正确示例：
GetOrder(ctx context.Context, orderID String) (*Order, Error) - 错误示例：
GetFromRedisOrFallbackToPostgres(ctx, id) - 若需差异化行为（如“强一致性查” vs “最终一致性查”），用不同方法名或加选项参数，而不是靠调用方拼接多个底层调用
- 所有错误返回统一包装为业务错误类型（如
ErrOrderNotFound），不透出redis.nil或sql.ErrNoRows
为什么嵌入接口比嵌入具体类型更安全
外观结构体字段类型必须是接口，否则会隐式绑定实现，破坏可测试性与替换能力。Go 没有“private 字段”语义，但接口即契约。
立即学习“go语言免费学习笔记（深入）”；
- 定义清晰的接口边界：
type CacheClient interface { Get(ctx context.Context, key string) (string, error) Set(ctx context.Context, key, value string, ttl time.Duration) error } - 测试时可轻松传入
mockCache，而无需启动 Redis 容器 - 后续替换为
memcached或redis-go-cluster时，只要满足接口，Facade无需改动 - 切忌用
*redis.Client或*badger.DB作为字段类型——这等于把实现钉死在结构体上
真正难的不是写出一个能跑的 Facade，而是判断哪些逻辑该放进它、哪些该留在服务层；以及当某次发布后发现缓存失效策略要改，你是否还能在不碰业务代码的前提下，只动 Facade 的一个方法。