不能——go 中私有方法无法被直接测试，因首字母小写标识符包外不可见；export_test.go 仅用于跨包共享测试辅助代码，不改变作用域规则。
私有方法能被测试吗？Go 的答案很直接
不能——Go 没有“测试专用访问权限”这回事。私有标识符（首字母小写）在包外不可见，export_test.go 也不是魔法开关，它只是个命名约定，不改变作用域规则。想测私有方法，得靠设计调整，不是靠文件名绕过语言约束。
export_test.go 的真实作用：跨包共享测试辅助代码
它只解决一个问题：让当前包的测试辅助函数、类型或变量，能被其他包的 *_test.go 文件导入使用。比如你写了一个通用断言函数 mustParseURL，放在 export_test.go 里，其他包的测试就能 import "yourmodule/internal"（假设包路径是 internal）然后调用它。
-
export_test.go必须和主包同名（即和main.go或lib.go在同一包内），不能属于xxx_test包 - 它会被
go test编译进测试二进制，但不会参与非测试构建 - 它对“测试私有方法”毫无帮助——私有方法依然无法从外部包调用
- 常见误用：把私有方法挪到
export_test.go里以为就能测，结果编译报错undefined: xxx
真正可行的三种做法（按推荐顺序）
测不到私有方法，本质是封装太紧或职责不清。优先从设计入手：
- 把逻辑抽成导出的纯函数：比如
calculateScore原本是user结构体的私有方法，把它拆成独立函数CalculateScore(score, bonus int) int，导出并直接测试 - 通过导出方法间接覆盖：私有方法通常被某个导出方法调用，确保该导出方法的输入/输出足够丰富，能触发所有分支。例如
User.Login()内部调用了私有validateToken，就用不同 token 构造测试用例 - 用内部测试包 + 接口抽象：如果私有逻辑涉及依赖（如数据库、http 客户端），把它定义为接口，私有方法接收该接口；测试时传入 mock 实现。这时私有方法本身仍不可导出，但行为可验证
为什么硬测私有方法会踩坑
强行绕过 Go 的可见性机制，短期看似“快”，长期代价高：
立即学习“go语言免费学习笔记（深入）”；
- 改个函数名就得同步改所有测试，违反封装原则
- 用
reflect调用私有方法：代码脆弱、性能差、ide 无法跳转、静态检查失效 - 把私有方法移到
xxx_test.go：它变成仅测试包可见，主包代码反而用不了，逻辑割裂 - 滥用
export_test.go暴露内部状态：比如导出一个TestHelper结构体去读私有字段，等于把实现细节钉死在测试里
Go 的测试哲学是“测行为，不测实现”。一个没被任何导出方法调用的私有方法，大概率不该存在——要么删掉，要么说明它本该是公开的。