Go测试中优先用函数类型桩替代interface{}，轻量且避免过度抽象；需注意全局桩重置、HTTP客户端应注入而非修改DefaultClient、数据库慎用sqlmock而倾向内存实现、并发下桩状态须线程安全。
Go 测试中用 func 替换依赖比 interface{} 更轻量
直接用函数类型做桩，不强制抽象接口，能避开“为测试而接口”的设计负担。尤其适合工具类、纯逻辑函数（如 time.Now、rand.Intn）的替换。
常见错误是把桩写成全局变量却忘了在 TestMain 或每个 TestXxx 里重置，导致测试间污染。
- 用包级变量声明桩：
var nowFunc = time.Now - 测试中覆盖：
nowFunc = func() time.Time { return time.Unix(123, 0) } - 务必在
defer中恢复原值，或用t.Cleanup：t.Cleanup(func() { nowFunc = time.Now }) - 不要对方法接收者做函数赋值（比如
*http.Client.Do），Go 不允许直接赋值方法值，得封装成普通函数
Stub HTTP 客户端时别动 http.DefaultClient
改 http.DefaultClient 看似简单，但会污染整个进程，影响并行测试、pprof、甚至其他第三方库的 HTTP 调用。
正确做法是让被测代码接受一个可注入的 *http.Client，测试时传入 &http.Client{Transport: &http.Transport{RoundTrip: stubRoundTrip}}。
stubRoundTrip是实现http.RoundTripper的闭包，可按 URL 或 Header 返回预设响应- 避免用
httptest.Server：它起真实 HTTP 服务，有端口占用、延迟、goroutine 泄漏风险；Stub Transport 零开销 - 注意
http.Client.Timeout在 Stub 下仍会生效，若桩函数卡住，测试可能超时而非报错
数据库操作桩慎用 sqlmock，优先考虑内存实现
sqlmock 本质是拦截 database/sql 的驱动调用，对 SQL 语句做字符串匹配，极易因空格、换行、参数顺序等细节失败，且无法验证事务行为。
更稳的方式是让 DAO 层依赖 sql querier 接口（如 interface{ QueryRow(string, ...any) *sql.Row }），测试时传入内存实现（如用 map 模拟表）。
- 内存实现可精确控制返回 error 类型（如
sql.ErrNoRowsvs 自定义 error），便于测分支逻辑 sqlmock的ExpectQuery默认区分大小写，SELECT和select匹配失败——得加sqlmock.QueryMatcherOption(sqlmock.QueryMatcherEqual)- 若必须用
sqlmock，记得调用mock.ExpectationsWereMet()，否则未命中的 expect 不报错
并发场景下 Stub 的状态必须线程安全
当被测代码启动 goroutine（如异步回调、定时重试），桩函数可能被多个 goroutine 同时调用。用普通 map 或计数器会 panic。
不是所有测试都跑在单 goroutine 里，尤其用了 t.Parallel() 或被测逻辑含 go 关键字时。
- 共享状态一律用
sync.Mutex或sync/atomic，例如记录调用次数：var callCount int64; atomic.AddInt64(&callCount, 1) - 避免在桩函数里 sleep 或阻塞，这会让测试变慢且不可控；想模拟延迟，应在桩外控制（如用
time.AfterFunc触发回调） - 如果桩要返回不同结果（如第一次失败、第二次成功），用原子计数器 + switch，别用闭包捕获的局部变量——它在并发下不可靠
真正难的不是写桩，而是判断哪一层该被桩、哪一层该被集成。比如 JWT 解析逻辑用内存 key 桩就行，但 OAuth2 token 刷新流程，往往需要真实 HTTP 响应结构才能暴露边界问题——这时候 Stub 就该让位给最小化集成。
