Mock对象在Go测试中什么时候会被GC？
Go的mock对象本身没有特殊生命周期管理，它们和普通结构体一样，只要没被任何活跃变量引用，下一次GC就会回收。但问题往往出在「你以为它没被引用」——比如testify/mock里注册的Expect方法调用记录、全局MockCtrl未Finish、或者测试函数里意外捕获了mock实例的闭包。
- 使用
gomock.Controller时，必须在每个测试末尾调用ctrl.Finish()，否则未验证的期望会持续持有mock引用 - 避免在
init()或包级变量中创建mock实例，这类对象生命周期与包绑定，测试间无法隔离 - 如果mock对象嵌套在channel、goroutine或延迟函数中（如
defer func() { use(mock) }()），需确认goroutine已退出、channel已关闭，否则引用链不会断
testify/mock + gomock混用导致的泄露典型场景
很多人在同一个测试里同时用testify/mock（基于反射的mock）和gomock（基于代码生成），结果发现内存占用随测试数量线性增长。根本原因是两者对「mock注册表」的管理逻辑不兼容：testify/mock内部维护一个全局mocks map，而gomock.Controller的Finish对它完全无效。
- 不要在一个测试文件中混用两种mock框架；选一个并坚持到底
- 若必须用
testify/mock，每次测试后手动清空：调用mock.Mock.AssertExpectations(t)后，再执行mock.ClearAllMocks() -
gomock生成的mock类型不能直接传给testify/assert的Equal做比较——这会触发深层反射遍历，意外延长临时mock对象的存活时间
HTTP handler测试中mock server和client的生命周期错位
写集成式HTTP测试时，常见做法是用httptest.NewServer启动mock服务，再用http.Client请求它。但NewServer返回的*httptest.Server必须显式调用Close()，否则底层listener和goroutine一直挂着，连带它内部引用的所有handler（含mock对象）都无法释放。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 务必在
defer srv.Close()前确保srv非nil；若NewServer失败，srv为nil，直接Close()会panic - 不要复用
http.Client实例跨测试——它的Transport可能缓存连接和中间件，间接持有了handler中的mock依赖 - 如果handler里用了
context.WithTimeout并传入mock对象，注意timeout触发后context cancel并不自动释放mock，只是断开等待链
go test -race检测不到mock泄露，但pprof能看见
竞态检测器只管goroutine间共享变量读写冲突，不关心内存是否该被释放。mock泄露属于「逻辑性内存泄漏」，表现为测试进程RSS持续上涨，但-race完全沉默。真正有效的观测方式是结合go tool pprof看堆分配热点。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go test -gcflags="-m -m" ./... 2>&1 | grep "moved to heap"，检查mock相关结构体是否被逃逸分析标记为heap-allocated - 加
-memprofile=mem.prof跑测试，用go tool pprof mem.prof查看top alloc_objects，重点关注mock生成的struct或interface{}类型 - 注意：
runtime.ReadMemStats在测试中拿不到精确值，因为GC可能被测试并发干扰；优先信pprof的heap profile
mock对象本身不特殊，但Go里任何引用关系都可能变成隐式生命周期绑定。最常被忽略的是测试辅助函数里返回的闭包——它看着像临时值，实际悄悄捕获了整个mock实例。
