Go函数打桩核心是控制返回值以保障测试可重复性，分函数变量替换（轻量、无需编译参数）和gomonkey二进制patch（需-gcflags=-l且严格匹配签名）两种方式。
Go 里调试函数时打桩，不是为了“绕过”函数，而是为了控制它的返回值或行为，让测试可重复、可隔离。核心就两条路：改函数变量（轻量）或用 gomonkey（强替换）。
给函数打桩必须关闭内联优化
Go 编译器默认会把小函数内联（inline），导致 gomonkey.ApplyFunc 找不到原始函数入口，直接 panic：panic: function xxx is inlined。
- 所有用
gomonkey打桩的测试，必须加编译参数：-gcflags=-l - 运行命令示例：
go test -gcflags=-l ./... -v - 不加这个参数，桩根本不会生效，但也不会报错——只会静默失效
用函数变量替代硬编码调用（推荐初学者）
不依赖第三方库，靠 Go 自身机制实现可控替换，适合逻辑简单、只替换一两个函数的场景。
- 把要打桩的函数声明为包级变量，比如：
var timeNow = time.Now - 业务代码里调用
timeNow()而非直接写time.Now() - 测试中用
gostub.Stub(&timeNow, func() time.Time { return fixedTime }) - 优点：无编译参数依赖、线程安全、易理解；缺点：需要提前设计变量抽象
用 gomonkey 打桩必须严格匹配签名
gomonkey.ApplyFunc 是运行时二进制 patch，对函数签名零容忍——参数个数、类型、顺序、返回值类型，差一点就 panic：panic: function signature mismatch。
立即学习“go语言免费学习笔记（深入）”；
- 例如想桩
cache.Get(ctx context.Context, key string) (string, error)，桩函数必须写成：func(ctx context.Context, key string) (string, error) - 不能少
context.Context，不能把error换成*errors.Error，也不能多一个log.Logger参数 - 常见坑：误把
io.Reader当成*os.File，或把int64和int当作等价类型
方法打桩比函数打桩多一层 receiver 类型约束
给结构体方法打桩（如 (*MyClient).DoRequest）时，ApplyMethod 第一个参数必须是具体实例或指针类型，不能传接口。
- 错误写法：
ApplyMethod(MyInterface{}, "DoRequest", stub)→ panic：无法识别接口方法地址 - 正确写法：
ApplyMethod(&MyClient{}, "DoRequest", stub)或先 new 一个实例再传 - receiver 类型必须和原方法定义完全一致：值接收器就传值，指针接收器就传指针
- 如果方法在 interface 中定义但实际由 struct 实现，桩只能打在 struct 上，不能打在 interface 变量上
真正难的不是写桩，是判断该不该打——比如 os.ReadFile 可以桩，但 fmt.Sprintf 通常没必要；桩太多说明接口抽象不够，桩太随意会导致测试脆弱。留心那些依赖时间、文件、网络、全局状态的函数，它们才是打桩的第一目标。
