Go中直接套用传统设计模式别扭，因其无类继承、接口隐式实现且重组合轻继承；应优先用函数类型、窄接口和defer封装替代工厂、策略及模板方法等重抽象模式。
为什么 Go 里直接套用传统设计模式常显得别扭
Go 没有类继承、没有泛型（旧版）、接口是隐式实现，且鼓励组合优于继承——这意味着照搬 Java/C++ 的 FactoryMethod、Observer 或 TemplateMethod 往往导致过度抽象、接口膨胀，甚至引入不必要的间接层。
真正提升复用的不是“用了什么模式”，而是是否解决了以下问题：
- 同一逻辑在多个地方重复判断（如重试、超时、日志埋点）
- 业务流程中存在可插拔的环节（如支付渠道切换、校验规则扩展）
- 资源生命周期管理不一致（如连接池、临时文件、goroutine 清理）
用函数类型和接口组合替代“经典”工厂与策略
Go 中最轻量、最自然的策略抽象就是函数类型；而工厂逻辑往往只需一个返回具体类型的函数，无需单独定义 Factory 接口。
例如统一处理 HTTP 客户端行为：
立即学习“go语言免费学习笔记（深入）”；
type HTTPDoer func(*http.Request) (*http.Response, error)
<p>func WithRetry(doer HTTPDoer, maxRetries int) HTTPDoer {
return func(req <em>http.Request) (</em>http.Response, error) {
var err error
for i := 0; i <= maxRetries; i++ {
resp, err := doer(req)
if err == nil {
return resp, nil
}
if i == maxRetries {
break
}
time.Sleep(time.Second * time.Duration(1<<uint(i)))
}
return nil, err
}
}</p><p>// 使用：原生 client.Transport.RoundTrip 可直接传入，无需包装成 struct
client := &http.Client{Transport: http.DefaultTransport}
doer := HTTPDoer(client.Do)
retryDoer := WithRetry(doer, 3)
这种写法比定义 Doer 接口 + 多个实现 struct 更直接，也更容易单元测试（直接传入闭包模拟失败）。
接口应窄而具体，避免“大而全”的 Service 接口
常见错误是定义一个覆盖所有方法的 UserService 接口，结果每个测试 mock 都要实现 8 个方法，其中 7 个永远返回 nil。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
更有效的做法是按调用方需要拆分：
-
UserReader：只含GetByID、List -
UserWriter：只含Create、Update -
UserNotifier：只含SendWelcomeEmail
这样 handler 层可只依赖 UserReader，repo 实现可同时满足多个小接口，测试时也只需 mock 2–3 个方法。Go 的接口隐式实现天然支持这种“按需契约”。
defer + 匿名 struct 封装资源清理，比模板方法更 Go-ish
Java 中常用 try-with-resources 或 AbstractTemplate.execute() 确保 cleanup；Go 里更惯用 defer 配合短生命周期结构体封装。
例如操作临时目录并确保删除：
func ProcessInTempDir(fn func(dir string) error) error {
dir, err := os.MkdirTemp("", "process-*")
if err != nil {
return err
}
defer os.RemoveAll(dir) // 不依赖父类或钩子函数
<pre class="brush:php;toolbar:false;">return fn(dir)}
// 调用方完全不用关心清理逻辑 err := ProcessInTempDir(func(dir string) error { return os.WriteFile(filepath.Join(dir, "data.txt"), []byte("ok"), 0644) })
这种模式比定义 TempDirProcessor 抽象类 + before/after 钩子更简洁，也避免了“为了复用而继承”的反模式。
真正难的不是选哪个模式，而是判断某段逻辑是否值得抽象——如果只被调用两次，就先复制；等到第三次出现相似结构，再把共性抽成函数或小接口。过早抽象是 Go 项目里最常见的复用陷阱。
