私有函数不可被外部包直接调用，测试文件须与源文件同目录且同包名（如package mypkg）才能访问；应优先通过导出函数的输入输出覆盖私有逻辑，而非强行导出或滥用//go:linkname。
私有函数在 Go 中无法被外部包直接调用
Go 的包级访问控制由首字母大小写决定：func doSomething() 是私有的，func DoSomething() 才是导出的。测试文件（如 xxx_test.go）虽然和被测代码同属一个包，但必须放在同一目录、使用相同包名（不能加 _test 后缀），才能访问私有符号。
常见错误是把测试文件误放到子目录，或声明了 package mypkg_test —— 这会让测试运行在独立包中，导致编译报错：cannot refer to unexported name mypkg.doSomething。
- 确保测试文件与源文件同目录，且包声明为
package mypkg（不是mypkg_test） - 不推荐为测私有函数而强行导出（如改成
DoSomething），这会污染接口契约 - 若函数逻辑极复杂、又确实需要隔离验证，可考虑将其提取为包级变量（
var doSomethingFunc = doSomething），在测试中替换为 mock 实现
优先通过导出函数的输入/输出覆盖私有逻辑
Go 测试哲学强调“测行为，而非实现”。大多数情况下，私有函数只是导出函数的内部拆分，只要导出函数的测试用例足够完备，私有逻辑自然被覆盖。
例如 ProcessData() 内部调用了私有 validateInput() 和 transform()，你只需构造边界输入（空数据、非法格式、超大负载）并断言 ProcessData() 的返回值、错误、副作用（如是否写入了某个全局 map），就间接验证了所有私有路径。
- 用
reflect.DeepEqual()比较结构体返回值，注意导出字段限制 - 对有副作用的私有函数（如修改包级变量），可在测试前备份并在
defer中恢复 - 避免“为了测而测”：如果一个私有函数从未被任何导出函数调用，它大概率是死代码
用 go:build + //go:linkname 绕过访问限制（仅限调试）
//go:linkname 是 Go 的底层机制，允许跨包链接符号，但它绕过了语言的可见性检查，属于非安全操作，仅应在临时调试、性能剖析或极端集成测试中使用，绝不可出现在 CI 或生产相关流程中。
示例：想在 mypkg_test.go 中直接调用 mypkg.unexportedHelper()，需先确保两者编译进同一二进制：
//go:build ignore // +build ignore package main import "mypkg" //go:linkname testHelper mypkg.unexportedHelper var testHelper func() int func main() { _ = testHelper() }- 必须添加
//go:build ignore构建约束，防止被常规构建包含 - 链接目标必须是已编译的符号名（可用
go tool objdump -s unexportedHelper ./mypkg.a查看） - 一旦源码重构（如重命名私有函数），链接会静默失败或引发 panic，难以调试
真正该警惕的是“为什么需要测这个私有函数”
当反复纠结如何测试某个私有函数时，更值得停下来问：它的职责是否过重？是否本该是一个独立的、可导出的小工具包？或者它和当前包耦合太深，导致难以被上层逻辑驱动？
比如一个 parseConfig() 私有函数，如果它涉及大量正则匹配和嵌套校验，与其在主包里硬测，不如把它抽成 configparser 子包，导出 Parse() 并单独测试——这样既提升复用性，也消除了访问障碍。
测试困难往往是设计信号。Go 的简洁性不在于语法少，而在于它用可见性规则倒逼你思考模块边界。