Go中符合单一职责的struct应仅保留数据字段和纯计算方法，I/O、加密等副作用逻辑须分离至独立类型并通过接口注入。
Go 里怎么写符合单一职责的 struct
Go 没有 class，但 struct + 方法组合很容易写出“啥都干”的类型。比如一个 User struct 同时处理数据库存取、HTTP 序列化、密码哈希、日志打点——这不是扩展性，是耦合炸弹。
真正管用的做法：按「变更原因」切分职责。用户数据结构归 User，存取逻辑放 UserRepository，密码逻辑抽成 PasswordService。
-
User只保留字段和极简方法（如IsAdmin()这种纯计算） - 所有 I/O、加密、网络调用，必须落在独立类型里，且依赖通过接口注入（不是直接 new）
- 避免在
struct方法里调用log.Printf或db.Query—— 这些是副作用，该由上层协调
interface{} 和空接口在依赖倒置中怎么用才不翻车
很多人以为“用了 interface{} 就算面向接口编程”，其实完全相反：interface{} 是类型擦除，它让编译器失去约束，根本没法实现依赖倒置。
真正的依赖倒置，是定义**窄而具体**的接口，只暴露被调用方真正需要的方法。比如仓储层不该依赖 DB 具体类型，而应依赖：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type UserRepository interface {
Save(u *User) error
FindByID(id int) (*User, error)
}
- 接口定义在**使用方包里**（比如 domain 包），而不是实现方（比如 infra 包）——否则还是倒过来依赖
- 禁止把
io.Reader当万能抽象塞进业务逻辑；它适合底层 IO，不适合表达“我能加载配置”这种领域语义 - 接口方法数控制在 3 个以内，超过就说明职责又混了
为什么 Go 的组合比继承更适合开闭原则
Go 不支持继承，但恰恰因此更自然地支持开闭原则：对扩展开放，对修改关闭。关键不是“能不能加新类型”，而是“加新行为时，要不要动老代码”。
典型错误是写一堆 if-else 分支处理不同策略，然后每次加新策略都要改那个大 switch。正确路径是用组合+接口：
- 定义策略接口，如
Notifier，含Send(msg string) error - 每种通知方式（Email、Slack、SMS）各自实现，互不干扰
- 主逻辑只依赖
Notifier接口，新增一种通知方式，只需新增一个实现，不用碰原有逻辑 - 注意：别为了组合而组合——如果只有两种实现且永不扩展，硬套接口反而增加认知负担
Go 中的“里氏替换”其实只有一条底线
Go 没有子类概念，所谓里氏替换，实际就一条：任何实现了某接口的类型，代入该接口变量后，行为必须符合该接口文档承诺的契约。不是语法能过，是语义不能崩。
常见崩坏点：
- 接口方法文档说“返回非 nil error 表示失败”，结果某个实现遇到空输入直接 panic —— 这违反契约
-
Cache.Get(key string) (any, bool)要求第二个返回值为true仅当 key 存在，但某个内存实现把超时也返回false—— 调用方会误判为 key 不存在 - 不要在接口方法里偷偷改接收者状态（比如缓存实例内部计数器），除非文档明确声明这是副作用行为
接口文档比代码更重要。没文档的接口，没人敢替换实现。
