Go中应优先用interface+依赖注入替代硬编码依赖，将数据库、HTTP客户端等抽象为接口并作为参数传入构造函数，便于测试mock和环境切换；工厂函数统一创建复杂对象，策略模式用map[string]func封装算法分支，组合优于嵌套，通过embed接口实现横切逻辑复用。
用 interface + 依赖注入替代硬编码依赖
Go 没有类继承，但通过 interface 定义契约、用结构体实现、再把依赖作为参数传入，能轻松替换行为而不改调用方。硬编码 new(SomeService) 会锁死实现，导致相同逻辑在多个地方重复构造。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把可变部分（如数据库、HTTP 客户端、缓存）抽象为
interface，例如type UserRepository interface { GetByID(id int) (*User, error) } - 构造函数接收这些接口，而非具体类型：
func NewUserService(repo UserRepository) *UserService - 测试时直接传入 mock 实现；上线时注入真实 DB 或内存缓存实现 —— 同一份业务逻辑复用在不同环境
工厂函数统一创建复杂对象
当结构体初始化需要校验、默认值填充、资源预分配（如连接池），或存在多种变体（FileLogger / CloudLogger），裸写 &Logger{...} 会散落在各处，难以收敛和升级。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义工厂函数，如
func NewLogger(cfg LoggerConfig) Logger，内部完成校验、默认值合并、资源初始化 - 若需多态创建，返回
interface{}或更具体的接口，避免暴露具体类型 - 配置结构体用指针接收（
func NewLogger(cfg *LoggerConfig)），方便 nil 判断和零值 fallback
策略模式用 map[string]func 封装算法分支
if/else 或 switch 处理支付方式、压缩算法、序列化格式时，新增一种实现就得改主逻辑，违反开闭原则，也容易漏掉某处的 case 分支。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义统一输入输出签名的函数类型：
type Processor func([]byte) ([]byte, error) - 用
map[string]Processor注册所有策略：processors["gzip"] = gzipProcess - 运行时按 key 查找执行，新增策略只需注册，不碰调度代码
- 注意并发安全：注册应在 init 阶段或加锁，运行时查表是无锁的
组合优于嵌套：用 embed + 接口复用通用能力
想让多个结构体都具备重试、超时、日志打点能力，不要每个都重写 DoWithRetry 方法，也不要用匿名字段强行“继承”—— Go 的 embed 是编译期静态组合，必须配合接口才能动态替换行为。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把横切逻辑抽成独立结构体，实现明确接口（如
type Retrier interface { Do(fn func() error) error }） - 在业务结构体中 embed 该接口字段：
retrier Retrier，而不是 embed 具体类型 - 构造时注入不同实现（带 exponential backoff 的、mock 不重试的、测试用固定失败次数的）
- 避免 embed 具体类型（如
retrier *DefaultRetrier），否则又回到强耦合
type Service struct {
retrier Retrier
db Database
}
func (s *Service) CreateUser(u User) error {
return s.retrier.Do(func() error {
return s.db.Insert(&u)
})
}
真正难的不是写出某个模式，而是判断什么时候该收口、什么时候该开放；比如一个 Processor map 看似灵活，但如果策略之间共享状态或需要生命周期管理，就得退回到接口+依赖注入。复用率高不高，最终看的是变化点是否被隔离到最小、最易替换的单元里。 
