Go微服务中真正落地的解耦模式只有外观、观察者、依赖注入和单例四种：外观统一串行/并发调用与错误兜底；观察者通过消息队列异步通知；依赖注入靠构造函数+接口显式传递；单例用sync.Once保障线程安全初始化。
Go微服务里真正能立刻落地、每天都在写的解耦模式就那么几个，不是教科书上列满24种，而是你在写 main.go、调 grpc.Invoke、加超时或熔断时，实际卡住你、逼你重构的那几类。
外观模式：API网关层怎么聚合多个服务调用？
外观模式不是为了“封装”，而是为了解决「串行调用失败后要不要继续」这个具体问题。它只负责“怎么串”，不负责“为什么串”——比如 VIP 用户才查积分这种逻辑，必须下推到下游服务，外观层不能掺和。
- 核心是把多个子服务调用收口到一个方法里，统一加
context.WithTimeout、统一处理错误兜底（如返回"N/A"） - 别在外观里做业务分支判断；否则下次改规则就得动网关，破坏了服务边界
- 真实项目中，
apiImpl.Test()里对a.a.TestA(ctx)和a.b.TestB(ctx)的调用顺序、是否并发、是否允许部分失败，都得在这里明确决策
观察者模式：订单创建后如何通知库存、短信、日志而不耦合？
观察者模式在 Go 微服务里几乎等于「事件 + 消息队列」，内存里维护 []Observer 切片只适合单实例调试，生产环境必须异步发布。
- 正确做法是用
nc.Publish("order.created", data)这类消息代理接口，让各服务自己订阅 - 千万别在
Notify()里同步调多个Update()，一个卡住整个流程就挂了 - 事件结构体要稳定，字段增减需兼容旧消费者；推荐用 Protobuf 定义，避免 JSON 字段名拼错引发静默失败
依赖注入：怎么让 UserService 不知道 DB 和 EmailSender 具体怎么初始化？
Go 没有运行时 DI 容器，但靠构造函数传参 + 接口抽象就能实现干净解耦，Wire 工具只是帮你生成编译期代码，不是必需品。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 定义
EmailSender接口，而不是直接依赖smtp.Client；测试时可轻松替换为 mock 实现 -
NewUserService(db *sql.DB, sender EmailSender)是关键入口，所有依赖显式声明，不藏在包级变量里 - 避免循环引用：repository 层不能 import service 层；分层结构必须是 handler → service → repository 单向依赖
单例模式：DB、Config、Logger 等全局资源怎么安全复用？
单例不是为了“全局唯一”，而是为了控制资源生命周期和并发安全。直接暴露包级变量（如 var db *sql.DB）在并发场景下极易出错。
- 必须用
sync.Once包裹初始化逻辑，否则多个 goroutine 同时调用GetDB()可能创建多个实例 - 单例对象本身要线程安全：比如
*sql.DB自带连接池，但自定义的Config结构体如果含 map，读写就得加锁或转为sync.Map - 警惕测试污染：单元测试中若复用同一单例，前一个 test 修改了状态，后一个 test 就可能失败；建议在测试 setup 中重置或使用临时实例
最常被忽略的是：解耦不是目标，而是手段。当一个 Test() 方法开始同时调用支付、风控、通知三个服务，且每个调用都要单独设超时、重试、降级时，你就该停下来想——这已经不是“解耦”，而是职责爆炸。此时真正该做的，往往是拆服务，而不是堆模式。
