可直接测试私有函数，只需将测试文件（如xxx.go）与被测函数置于同一包内，声明相同包名且不以_test.go结尾；该文件不会参与构建但会被go test加载，需显式指定运行。
Go 语言中不能直接从包外调用私有（小写首字母）函数，但测试私有函数并非不可能——关键在于「测试代码与被测函数是否在同一个包内」。
把测试文件放在被测包下，而不是 _test 包里
这是最直接有效的方式。Go 的包级可见性规则只看定义位置，不区分「源文件」还是「测试文件」。
- 确保测试文件名是
xxx.go（不是xxx_test.go），且和被测私有函数在同一个目录、声明为同一个包名（如package util） - 这样它就能像其他源文件一样访问
parseConfig、isValidToken这类私有函数 - 注意：这种测试文件不会被
go build编译进最终二进制，但会被go test加载执行
用 go test -run=TestName -v 精确运行单个私有函数测试
因为这类测试不在 *_test.go 文件里，go test 默认不会发现它们——必须显式指定文件和函数。
- 运行命令示例：
go test util/ -run=TestParseConfig -v - 确保该测试函数是导出的（首字母大写），比如
func TestParseConfig(t *testing.T) - 如果测试文件叫
config_internal.go，需确认它被go test正确加载（可加-x查看编译过程）
当私有逻辑太复杂时，考虑把它拆成导出函数 + 内部参数校验
不是所有私有函数都值得硬测。如果一个私有函数承担了核心业务逻辑（比如 JWT 签名验证、配置合并策略），它其实应该具备可测试性，这时重构比绕过规则更可持续。
立即学习“go语言免费学习笔记（深入）”；
- 把纯计算逻辑抽成导出函数（如
ValidateSignature），保留私有 wrapper 做参数预处理或上下文注入 - 导出函数本身无副作用、接受明确输入、返回明确输出，天然适合单元测试
- 避免把错误处理、日志、全局状态塞进私有函数里，否则即使能测，也容易因环境差异失败
真正难测的往往不是「私有性」，而是函数隐式依赖外部状态（如 os.Getenv、全局变量、未 mock 的 HTTP 客户端）。与其纠结能否调用私有函数，不如先检查它是否真的只做一件事。
