能。同包的_test.go 文件与普通。go 文件属同一包，可直接调用私有函数；若声明为独立包（如 myapp_test），则无法访问，需改用同包测试或导出函数。
私有函数能被同包的 _test.go 文件调用吗？
能。Go 的包级可见性规则里，“私有”只对 ** 跨包访问 ** 生效；同包下的 _test.go 文件和普通 .go 文件属于同一个包（比如都属于 myapp），因此可以直接调用 func helper() {} 这类私有函数。
常见错误现象：把测试文件放在独立的 myapp_test 包里（即文件开头写 package myapp_test），还试图直接调用 helper() —— 这时编译会报 undefined: helper。
- 同包测试：测试文件声明为
package myapp，文件名形如xxx_test.go - 必须和被测代码在同一个目录下
- 不需要导出函数名，
helper()就是可调用的 - 这种写法是 Go 官方推荐的私有函数测试方式，无任何 hack 成分
myapp_test 包里怎么测私有函数？
不能直接测。一旦测试文件声明为 package myapp_test，它就成了一个完全隔离的新包，无法看到 myapp 包里的未导出标识符。
有人尝试用反射或 unsafe 强行调用，但代价高、不可靠、破坏封装，且在 Go 1.20+ 中部分反射路径已被限制。
立即学习 “go 语言免费学习笔记（深入）”；
- 唯一合规路径：把想测的逻辑抽成导出函数（
Helper()），哪怕只在测试中用 - 或者改用同包测试（上一节方式），这是更轻量、更自然的选择
- 注意：
go test默认会同时编译myapp包和myapp_test包，但二者不共享作用域
同包测试会影响生产构建吗？
不影响。Go 编译器在构建非测试目标（如 go build）时，会自动忽略所有匹配 *_test.go 的文件。
也就是说，你的 helper_test.go 里写的测试函数、甚至额外引入的测试依赖（如 testify），都不会打进最终二进制里。
-
go build和go run main.go完全无视_test.go文件 -
go test才会加载它们，并且仍按包名决定是否能访问私有符号 - 不用担心测试代码污染生产环境或增大二进制体积
为什么不用导出函数代替私有函数来测试？
可以，但不总合适。导出意味着它进入了包的公共 API 表面，后续要承担向后兼容责任 —— 即使你只打算给测试用。
比如一个内部状态校验函数 isValidState(s state) bool，如果导出为 IsValidState()，别人可能误用，你也再不能轻易重命名或删掉它。
- 同包测试绕过了“导出即承诺”的约束，让测试更贴近真实使用边界
- 适合验证内部不变量、算法中间步骤、错误分支逻辑等不希望暴露的部分
- 真正的难点不在技术实现，而在于判断：这个函数是否真的只需内部可见？它的职责是否已足够清晰、稳定？
