可通过将测试文件置于同一包内直接测试私有函数；2. 推荐通过测试调用私有函数的公有函数来间接覆盖逻辑；3. 复杂私有函数可提取至内部包并导出测试；4. 避免使用反射强行调用，破坏封装性。
在Golang中，无法直接从外部包调用私有函数（即首字母小写的函数），但测试私有函数是常见需求。Golang的测试机制并不要求所有函数都必须被导出才能测试，你可以通过一些合理的方式实现对私有函数的有效测试。
将测试文件放在同一包中
Go 的测试文件（_test.go）可以放在同一个包中，这样就能访问该包内所有的私有函数和变量。
例如，你的代码在 package utils 中：
// utils/utils.go
package utils
func add(a, b int) int {
return a + b
}
// utils/utils_test.go
package utils
import "testing"
func TestAdd(t *testing.T) {
result := add(2, 3)
if result != 5 {
t.Errorf("期望 5，得到 %d", result)
}
}
只要测试文件在同一个包下，就可以直接调用 add 函数，无需导出。
立即学习“go语言免费学习笔记（深入）”；
通过公有函数间接测试
如果私有函数被某个导出函数调用，可以通过测试导出函数来覆盖私有逻辑。
这是更推荐的做法，因为测试应关注行为而非实现细节。
- 确保测试覆盖了使用私有函数的公共接口
- 借助覆盖率工具（go test -cover）检查私有函数是否被执行
提取私有逻辑到独立包（必要时）
若某个私有函数非常复杂且需要独立验证，可考虑将其移到一个内部子包中并导出。
例如：
// internal/calc/math.go
package calc
func Add(a, b int) int { // 导出函数
return a + b
}
然后在主包中调用它，并在测试中导入这个内部包进行测试。
不建议使用反射强行调用
虽然可以通过反射调用未导出函数，但这破坏了封装性，代码脆弱，也不利于维护。
例如：
// 非常不推荐！
reflect.ValueOf(target).MethodByName("privateFunc").Call(args)
这种方式容易出错，且在编译期无法检查，应避免。
基本上就这些。Go 的设计鼓励你通过良好的接口设计来组织代码，而不是强行测试每一个私有函数。只要保证核心逻辑被充分覆盖，是否“直接”测试私有函数并不关键。
