外观模式在Go中通过封装函数或定义结构体+方法集隐藏子系统复杂性，核心是降低调用方认知负担；适用于多模块协作、依赖频繁变动、需统一错误处理等场景，推荐用结构体实现以支持扩展与状态管理。
外观模式在 Go 里不是靠继承或接口抽象来实现的，而是靠「封装一组函数」或「定义一个结构体+方法集」来隐藏子系统复杂性。它不强制要求设计模式教科书式结构，关键看是否真正减少了调用方的认知负担。
什么时候该用外观模式（而不是直接写函数）
当多个包/模块协作完成一件事，且调用方每次都要手动导入、初始化、串联调用时，就该考虑外观了。比如：启动一个带日志、配置加载、数据库连接、HTTP 服务的 Web 应用——如果每次 main.go 都要重复写 log.New()、config.Load()、db.Open()、http.ListenAndServe()，那就该抽一个 App 结构体统一协调。
- 子系统组件变动频繁，但上层逻辑希望保持稳定
- 测试时想快速替换整套依赖（比如用内存 DB 替代真实 PostgreSQL）
- 对外暴露的 API 需要统一错误处理、超时控制、上下文传递
用结构体 + 方法实现外观（推荐）
比裸函数更易扩展、可组合、能携带状态。典型结构是定义一个 Facade 类型，把底层依赖作为字段，再提供高阶方法封装流程。
type App struct {
cfg *Config
db *sql.DB
log *log.Logger
srv *http.Server
}
func NewApp(cfgPath string) (*App, error) {
cfg, err := LoadConfig(cfgPath)
if err != nil {
return nil, err
}
db, err := sql.Open("postgres", cfg.DBURL)
if err != nil {
return nil, err
}
return &App{
cfg: cfg,
db: db,
log: log.New(os.Stdout, "[app] ", log.LstdFlags),
}, nil
}
func (a *App) Run() error {
a.log.Println("starting...")
a.srv = &http.Server{Addr: a.cfg.Addr, Handler: newHandler(a.db, a.log)}
return a.srv.ListenAndServe()
}
注意：NewApp 不应启动任何服务，只负责构建和校验依赖；Run 才触发执行。这样便于测试和生命周期控制。
立即学习“go语言免费学习笔记（深入）”；
避免把外观变成“上帝对象”
外观不是把所有功能塞进一个结构体。常见反模式包括：
- 给
App加上SendEmail()、ProcessImage()、CallThirdPartyAPI()等无关职责 - 让
App同时持有 Redis 客户端、gRPC 连接、WebSocket Hub —— 如果这些不参与同一业务流，就该拆成不同外观 - 在
Run()里做阻塞 I/O 而不提供Shutdown()或上下文支持，导致无法优雅退出
真正的简化，是让调用方只关心「我要做什么」，而不是「我得先初始化 A，再检查 B 是否 ready，再传 C 给 D」。外观一旦开始回答「怎么初始化」「哪个顺序调用」，它就算起作用了。
