go test 能直接测试私有函数，前提是测试文件与被测代码同包名（如均为 package utils），而非仅同目录；必须用 Test_ 开头命名测试函数（如 Test_validateToken），且不可用反射或 export_test.go 绕过可见性规则。
go test 能直接测私有函数，前提是测试代码和被测函数在同一个包里——不是同目录就行，必须同 package 声明。
测试文件必须声明与源码相同的包名
很多人把 utils_test.go 放在 utils/ 目录下，却写 package utils_test，结果一跑就报 undefined: validateToken。这不是路径问题，是包隔离了：Go 的可见性只认包名，不看文件位置。
-
utils.go里是package utils→ 测试文件也必须是package utils -
_test.go后缀只是告诉go test这是测试文件，不影响包作用域 - IDE 有时会自动生成
xxx_test包名，得手动改成和源码一致的包名 - 别用
export_test.go想“开后门”——它只用于导出测试辅助工具，对访问本包私有符号完全没用
Test_ 开头的函数名是合法且推荐的写法
go test 从 Go 1.21 起明确支持以 Test_ 开头的函数（如 Test_validateToken）作为测试入口，这是专为私有函数设计的稳定机制，不是临时 hack。
- 必须写成
Test_+ 小写函数名，比如func Test_validateToken(t *testing.T) - 不能写成
test_validateToken或TestvalidateToken——前者不匹配测试正则，后者首字母小写不导出，go test直接跳过 - 这种命名不会污染导出 API，也不违反 Go 的可见性约定
- 如果函数逻辑足够独立、契约清晰，更推荐把它重构为导出函数（如
ValidateToken），再写标准TestValidateToken
别用反射强行调用私有函数
用 reflect.ValueOf(privateFunc).Call() 确实能跑通，但会让测试变成“运行时契约”，脆弱得没法维护。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 函数签名一改，测试就 panic，而不是编译报错
- IDE 跳不到定义，静态检查失效，
go vet和 linter 都管不了 - 缺少
if !f.IsValid() || !f.CanCall()检查，很容易直接 panic - 适合临时调试或逆向分析，但绝不能进 CI 流水线——覆盖率数字好看，实际毫无保障
真正难测的往往不是“私有”，而是隐式依赖
很多私有函数看似难测，其实是因为它偷偷读了 os.Getenv、改了全局变量、或者调用了未 mock 的 HTTP 客户端。与其绕过可见性规则，不如先解耦。
立即学习“go语言免费学习笔记（深入）”；
- 把副作用操作（日志、时间、网络）抽成参数传入，比如
func validateToken(token string, now func() time.Time, client HTTPClient) - 用包级变量替换（如
var validateTokenFunc = validateToken），测试中可直接赋值 mock - 若函数被多个公有函数复用，且逻辑复杂，说明它本就该是可测试单元——这时重构比硬测更可持续
go test -cover），比写一堆 Test_ 更可靠。而一旦决定测，就老老实实同包、同名、Test_ 命名——别走捷径，捷径最后都得重走。 
