真正的红-绿-重构循环需以go test为节奏：红阶段只写最小失败测试（如仅断言errnotfound），绿阶段仅做最小通过改动（如return nil），重构阶段只优化实现而不改行为，辅以go vet等工具验证。
怎么启动一个真正的红-绿- refactor 循环
测试驱动开发在 Go 里不是“先写测试再写函数”这么简单。关键在于让 go test 成为你敲代码时的呼吸节奏——失败要快、反馈要准、重构要有依据。
- 红阶段必须只写最小可运行的失败测试，比如只断言
ErrNotFound，不碰具体业务逻辑；否则你根本分不清是接口错了，还是实现错了 - 绿阶段只做刚好让测试通过的事：能用
return nil就别写分支，能硬编码就别抽象；Go 的接口和结构体很轻，但过早封装会让后续重构卡住 - refactor 阶段不改任何测试行为，只动实现：提取函数、重命名变量、合并重复判断；这时
go vet和golint（或revive）该开就开，它们会揪出你重构时漏掉的 nil 指针或未使用的参数
典型错误：写完 TestCreateUser 就顺手把数据库连接、密码加密、事件发送全塞进 CreateUser 函数里——结果测试一跑就超时，失败信息里全是 context.DeadlineExceeded，根本看不出哪一行逻辑有问题。
如何隔离外部依赖，让测试真正快起来
Go 的测试慢，90% 是因为没切掉 HTTP 客户端、数据库、时间等外部依赖。不是靠 mock 工具，而是靠 interface + 依赖注入 + 可控构造函数。
- 把所有外部交互抽象成接口，比如
type EmailSender interface { Send(to, subject, body string) error }，而不是直接用smtp.SendMail - 构造函数接收这些接口作为参数，比如
NewUserService(db UserStore, emailer EmailSender)；测试时传入内存实现或空结构体，生产环境才传真实实例 - 时间相关逻辑一律通过
clock Clock接口注入（可用github.com/andres-erbsen/clock），避免time.Now()导致测试随机失败
常见坑：用 monkey.Patch 或 gomock 去 patch 标准库函数——Go 编译器可能内联 time.Now，patch 失效；而且这类 patch 会污染全局状态，多个测试并行跑时互相干扰。
立即学习“go语言免费学习笔记（深入）”；
重构时怎么判断“改得安全”，而不是凭感觉
Go 没有 IDE 级别的安全重构支持，所以得靠工具链+约定来兜底。
- 每次重构前先确认
go test -race能过；Go 的竞态检测器极其敏感，哪怕只是把一个 map 读操作移到 goroutine 里，它都会报Data Race - 对结构体字段做增删改前，先 grep 全局：
grep -r "MyStruct." ./... | grep -v "_test.go"；Go 不会像 Java 那样编译时报错，字段名变了但没人改调用方，测试照样过，线上才 panic - 用
go list -f '{{.Deps}}' .查看当前包依赖，如果发现重构后某个间接依赖变多了（比如加了encoding/json到原本纯算法包），说明你无意中把领域逻辑和序列化混在一起了
容易被忽略的一点：Go 的导出规则（首字母大写）让重构特别危险。把 userID 改成 UserID 看似只是大小写，但可能让下游包突然拿到一个新导出字段，而他们原来的 struct 字面量初始化就崩了——这种 break change 不会在测试里暴露，只会在编译期炸给调用方。
