Golang设计模式与代码可读性的平衡

go代码应追求行为直白、路径扁平、错误显式；接口仅在需mock或多实现时使用，否则优先函数值；依赖应显式传入而非容器注入；Context是运行时协作契约，非业务抽象，不可持久化或滥用WithValue。

设计模式用多了，代码反而更难懂

Go 语言没有类继承、没有泛型（早期）、不鼓励接口滥用，导致很多从 java 或 C# 转来的开发者下意识套用工厂、装饰器、观察者等模式，结果是 Interface{} 堆砌、NewXXXService 泛滥、三层嵌套构造函数。这不是“设计”，是“造轮子式遮掩”。Go 的可读性核心在于：**行为直白、路径扁平、错误显式**。一旦某个模式让 if err != nil 被藏进回调或中间件里，它就违背了 Go 的直觉流。

什么时候该用 interface，什么时候该直接传函数

Go 中最常被误用的设计元素就是 interface。不是所有抽象都需要定义新接口——尤其当只有一处实现时。比如日志写入，与其定义：

type Logger interface {     Info(msg string)     Error(msg string) } // 然后传入 logger Logger

不如直接接收：

func Process(data []byte, log func(string)) {     log("started")     // ... }

判断依据很简单：

立即学习“go语言免费学习笔记（深入）”；

• 是否需要 mock 测试？→ 是 → 用 interface
• 是否已有多个不同实现（如本地文件 / http / kafka）？→ 是 → 用 interface
• 是否只是临时钩子、调试输出、或单一上下文行为？→ 否 → 用函数值
• 接口方法超过 2 个？→ 高风险信号，大概率在模拟其他语言的“类”

避免 “Go 版 spring”：依赖注入容器的陷阱

像 dig、wire 这类工具本身没问题，但问题出在使用动机上。如果为了“解耦”而把 http.Handler、*sql.DB、cache.Store 全塞进一个容器，再靠 tag 或结构体字段名自动注入，你就失去了 Go 最重要的控制力——谁创建了什么、何时创建、生命周期在哪结束。

更轻量、更清晰的做法：

• 用普通函数组装依赖：func Newapp(db *sql.DB, cache cache.Store) *App
• 把初始化逻辑写在 main() 或 cmd/ 下，而不是藏在 inject.go 里
• 拒绝 Provide(func() X { ... }) 这种黑盒注册；每个依赖的创建过程必须肉眼可见
• 若真需 wire 生成代码，确保 wire.Build 调用链不超过 2 层，且所有 Wire 文件放在同一目录

Context 传递不是设计模式，是协议约定

很多人把 context.Context 当成一种“策略模式”来用：加 cancel、加 value、再 wrap 一层 timeout。但它的真正角色是 Go 运行时与用户代码之间的**协作契约**，不是业务抽象层。

常见污染点：

• 在 Struct 字段里存 context.Context → 错。Context 不该持久化，只该作为参数向下传
• 用 context.WithValue 传业务参数（如 user ID、trace ID）→ 危险。应改用显式参数或封装好的 request struct
• 在非阻塞函数里传 context → 多余。只有可能挂起的操作（I/O、select、time.Sleep）才需要它
• 忘记在 defer 中 cancel 子 context → 最常见泄漏源

记住：Go 没有“优雅停机模式”，只有 ctx.Done() 和手动 close。

最难的平衡点不在语法或工具，而在团队对“可读”的共识——有人觉得 5 行 if-else 比 1 行泛型管道更啰嗦，有人却觉得后者要翻 3 个文件才能看懂数据怎么变的。Go 的设计哲学不提供标准答案，只提供足够少的语法糖，逼你把选择写出来。