go 语言不支持直接对函数或方法（尤其是标准库中的未导出函数）进行打桩，但可通过依赖注入将函数作为参数传入，从而在测试时替换为模拟实现，实现可测试性与生产代码的解耦。
go 语言不支持直接对函数或方法（尤其是标准库中的未导出函数）进行打桩，但可通过依赖注入将函数作为参数传入，从而在测试时替换为模拟实现，实现可测试性与生产代码的解耦。
在 Go 中，由于函数是一等公民且标准库（如 os 包）中的函数（如 os.Getwd()）是包级导出函数而非接口方法，无法像面向对象语言那样通过继承或接口重写来 mock。testify/mock 等工具也仅适用于基于接口的依赖，对普通函数无效。因此，正确的实践不是“mock 函数”，而是重构代码以支持函数注入（Function Injection）——即把外部依赖（如 os.Getwd）作为参数显式传入，使逻辑与环境解耦。
✅ 推荐方案：依赖注入 + 双层函数封装
以 os.Getwd() 为例，假设你的业务逻辑需要处理工作目录获取失败的情况：
// production.go
package main
import (
"os"
)
// GetWorkingDir 是对外暴露的公共函数（供其他包调用）
func GetWorkingDir() (string, error) {
return getWorkingDir(os.Getwd)
}
// getWorkingDir 是可测试的内部函数，接收一个函数类型参数
func getWorkingDir(getwd func() (string, error)) (string, error) {
dir, err := getwd()
if err != nil {
return "", err // 或执行自定义恢复逻辑，如 fallback 到默认路径
}
return dir, nil
}
对应编写单元测试：
// production_test.go
package main
import (
"errors"
"testing"
)
func TestGetWorkingDir_WhenGetwdFails(t *testing.T) {
// 模拟 os.Getwd 返回错误
mockGetwd := func() (string, error) {
return "", errors.New("simulated Getwd failure")
}
_, err := getWorkingDir(mockGetwd)
if err == nil {
t.Fatal("expected error, but got nil")
}
if err.Error() != "simulated Getwd failure" {
t.Errorf("expected 'simulated Getwd failure', got %v", err)
}
}
func TestGetWorkingDir_WhenGetwdSucceeds(t *testing.T) {
mockGetwd := func() (string, error) {
return "/home/user", nil
}
dir, err := getWorkingDir(mockGetwd)
if err != nil {
t.Fatalf("unexpected error: %v", err)
}
if dir != "/home/user" {
t.Errorf("expected '/home/user', got %q", dir)
}
}
⚠️ 注意事项与最佳实践
- 避免全局变量或单例状态：不要用 var getwdFunc = os.Getwd 这类可变全局函数指针——它破坏并发安全性，且难以在并行测试中隔离。
- 保持函数签名一致：注入的函数类型必须与原函数完全匹配（包括参数、返回值、error 位置），否则类型不兼容。
- 优先使用接口抽象复杂依赖：若涉及多个相关方法（如 os.Stat, os.Open, os.Remove），建议封装为接口（如 Filesystem），再注入接口实例，比逐个注入函数更可维护。
- 生产代码零侵入：GetWorkingDir() 仍调用 os.Getwd，对使用者完全透明；测试仅需调用内部 getWorkingDir(...) 并传入模拟函数，符合“测试友好、生产简洁”原则。
这种模式不仅是解决 os.Getwd 的权宜之计，更是 Go 中实现可测试性的核心范式：将不确定性（I/O、时间、随机性等）抽象为可替换的行为，而非试图修改不可变的标准库。坚持此设计，你的代码将天然具备高内聚、低耦合与易验证的工程品质。
