应在出现重复条件分支、难以测试的硬编码依赖或新增类型需多处修改时引入设计模式；从策略模式替换if/else和switch起步，用接口+多实现+依赖注入解耦，避免goroutine泄漏与顺序假设。
什么时候该考虑引入设计模式
不是项目一开始就要套用设计模式，而是当出现重复的条件分支、难以测试的硬编码依赖、或每次加一个新类型就得改七八个
地方时，才说明「模式」是为解决真实痛点而来的。比如你发现 switch 语句在多个文件里反复判断 paymentMethod 类型，或者 http.Handler 里塞了大量业务逻辑导致单元测试必须启动 HTTP 服务——这时候才是引入的合理时机。
从策略模式开始替换 if/else 和 switch
这是 Golang 项目中最自然、副作用最小的起点。核心是把“根据输入选择行为”的逻辑，从控制流语句抽成接口 + 多个实现。
- 定义统一接口，如
type PaymentProcessor interface { Process(amount float64) error } - 为每种支付方式（
AlipayProcessor、WechatProcessor）实现该接口 - 用
map[string]PaymentProcessor替代switch paymentMethod，注册和查找都清晰可测 - 避免在接口实现里调用全局变量或直接写日志——这些应通过构造函数注入
var processors = map[string]PaymentProcessor{
"alipay": &AlipayProcessor{logger: log.Default()},
"wechat": &WechatProcessor{client: http.DefaultClient},
}
用依赖注入替代 new() 和全局单例
很多 Go 项目早期靠 new(MyService) 或包级变量（如 var db *sql.DB）串联组件，结果导致无法 mock、难以并行测试、配置耦合严重。
- 把依赖作为结构体字段声明，而不是在方法内创建，例如
type OrderService struct { repo OrderRepo; notifier Notifier } - 构造函数接收所有依赖，不主动调用
sql.Open或redis.NewClient—— 这些由上层（如main()）负责初始化并传入 - 用
interface{}定义仓储契约，而非直接依赖*sql.DB；这样测试时可用内存 map 实现快速验证 - 不要为了“注入”而引入重型框架（如 wire/dig），先用纯函数组合：一个
func NewApp(db *sql.DB, r *redis.Client) *App就够用
观察者模式要小心 goroutine 泄漏和顺序假设
Go 里常有人用 chan + go func() 实现事件通知，但容易忽略两个关键点：监听器 panic 会杀死整个 goroutine，且发布顺序 ≠ 接收顺序。
立即学习“go语言免费学习笔记（深入）”；
- 每个监听器应在独立的
go语句中执行，并用recover捕获 panic，避免影响其他监听器 - 如果业务要求严格顺序（如“先发短信再发邮件”），就不能依赖并发 goroutine 的执行次序——改用同步回调或显式队列
- 监听器注册后若长期不触发，需提供
Unsubscribe()或带 context 的注册方式，防止内存泄漏 - 别把事件数据指针直接发给多个 goroutine，尤其当数据会被修改时——要么传副本，要么确保只读
真正难的不是写出模式代码，而是识别出哪段逻辑正在重复承担“变化点”的职责。模式只是名字，背后是把“什么会变”和“什么不变”切开的意识。一旦开始按这个思路拆，你会发现有些地方根本不需要模式，只需要一个接口加两行注释。
