可直接测试私有函数，但须同时满足：测试文件与源码同包名、测试函数以Test_开头、被测私有函数位于同包内；任一条件不满足将导致undefined错误或被go test忽略。
能直接测，但必须满足三个硬性条件：测试文件和源码同包名、测试函数用 Test_ 命名、被测私有函数在同一个 Go 源文件或同包其他文件里。绕开任一条件都会报 undefined 或被 go test 忽略。
测试文件必须声明和源码相同的包名
很多人把 utils_test.go 放在 utils/ 目录下，却写 package utils_test，结果调用 validateToken 时编译失败，提示 undefined: validateToken。这不是路径问题，是包隔离了——Go 的可见性只认 package 声明，不看文件位置。
-
utils.go里是package utils→ 测试文件第一行也必须是package utils -
_test.go后缀只是告诉go test这是测试文件，不影响作用域 - IDE（如 Goland）常默认生成
xxx_test包名，得手动改成和源码一致的包名 - 别建
utils_internal或testutils这类新包——它和原包完全隔离，私有符号照样不可见
测试函数必须用 Test_ 命名（下划线紧接 Test）
go test 从 Go 1.21 起明确支持 Test_ 前缀作为测试未导出函数的稳定机制，不是临时 hack。它被工具链、IDE 补全、覆盖率统计完整识别。
- 被测函数是
func parseConfig() error→ 测试函数必须是func Test_parseConfig(t *testing.T) -
test_parseConfig（小写开头）：不匹配Test[A-Z]正则，go test直接跳过 -
TestParseConfig（驼峰）：会被当成测试导出函数ParseConfig，找不到就报错 -
Test_parseConfig是唯一合法写法，且与被测函数名严格对应，避免拼写偏差
别用反射或 export_test.go 强行突破可见性
这两种做法看似“能跑通”，实则引入严重维护风险，且违背 Go 的设计哲学。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
reflect.ValueOf(privateFunc).Call()：函数签名一改就 panic，IDE 跳不到定义，go vet和 linter 失效，CI 里跑着像模像样，实际毫无保障 -
export_test.go不是用来测私有函数的——它只解决跨包共享测试辅助代码的问题（比如通用断言函数），对访问本包私有符号完全没用 - 把私有函数挪进
export_test.go？它变成仅测试包可见，主包代码反而调不到，逻辑割裂 - 用
//go:linkname？属于非安全操作，仅限临时调试，绝不能进 CI 或生产流程
真正难测的往往不是“私有”，而是隐式依赖
很多私有函数看似难测，其实是因为它偷偷读了 os.Getenv、改了全局变量、或调用了未 mock 的 HTTP 客户端。与其硬刚可见性规则，不如先解耦。
- 把副作用抽成参数：比如
func validateToken(token string, now func() time.Time, client HTTPClient) - 用包级变量替换：如
var validateTokenFunc = validateToken，测试中可直接赋值 mock - 优先通过导出函数覆盖：如果
ProcessData()内部调用了validateInput()和transform()，构造边界输入（空数据、非法格式）并断言返回值和副作用，就能间接验证所有私有路径 - 一个没被任何导出函数调用的私有函数，大概率是死代码——要么删掉，要么说明它本该是公开的
最易被忽略的一点：测试文件必须和源码在同一个目录下。哪怕包名对了、命名对了，如果 utils_test.go 被误放到子目录（比如 utils/test/），go test 会把它当做一个独立包处理，依然报 undefined。
