go中测试私有函数应优先通过公有函数间接验证行为；同包测试文件（_test.go与源码同包）可直接调用私有函数，是官方推荐方式；复杂依赖场景宜用接口抽象与依赖注入；禁止为测试导出或包装私有函数。
在 Go 中，私有函数（首字母小写）无法被其他包直接调用，因此不能像公有函数那样在外部测试文件中直接调用。但测试私有逻辑并非必须暴露它——关键在于测试行为而非可见性。推荐做法是：通过导出的公共函数或接口间接覆盖私有逻辑；必要时可借助包内测试（_test.go 与源码同包）直接调用；不建议为测试而改名导出或加包装器“绕过”封装。
优先通过公有入口测试私有函数
大多数私有函数是辅助性的，服务于某个导出函数的内部逻辑。只要该导出函数的行为完整、边界清晰，就可以通过输入输出验证其背后私有逻辑是否正确。
- 例如：
ParseConfig()内部调用私有函数validateFormat()，你只需传入非法格式的配置字符串，断言返回错误即可 - 避免重复测试：不必单独测
validateFormat("invalid")，除非它被多个导出函数复用且逻辑复杂 - 好处：不破坏封装，测试稳定，重构私有实现时测试无需修改
同包测试：直接调用私有函数（最常用且合理）
Go 的测试惯例允许 xxx_test.go 文件与被测代码放在同一包中（即不加 _test 后缀的包名），此时私有标识符完全可见。
- 命名方式：源文件为
utils.go（package utils），测试文件为utils_test.go（也声明package utils） - 这样就能直接调用
parseHeader()、buildURL()等私有函数并编写针对性单元测试 - 这是 Go 官方推荐方式，
net/http、strings等标准库大量使用
通过接口抽象 + 依赖注入测试复杂私有行为
当私有函数涉及 I/O、时间、随机性或外部依赖时，可将其逻辑提取为接口，再通过依赖注入让测试能替换实现。
立即学习“go语言免费学习笔记（深入）”；
- 例如：私有函数
sendRequest()依赖 HTTP 客户端，可定义HTTPDoer接口，接收Do(*http.Request) (*http.Response, Error) - 主逻辑函数接收该接口作为参数（或通过结构体字段注入），测试时传入 mock 实现
- 注意：这不是为了“测试私有函数”，而是为了解耦可测性；接口本身应导出，但具体实现仍可私有
不推荐的做法：包装导出或强行改名
为测试而将 processData() 改成 ProcessData()，或新增一个导出的 TestProcessData() 包装器，会污染 API、误导使用者，并增加维护负担。
- 导出即承诺：一旦导出，就要考虑向后兼容、文档、用户误用等问题
- 包装器只是把问题藏得更深，没解决设计问题，反而让调用链变长、语义模糊
- 如果真需要跨包复用某逻辑，应重新评估是否本就该设计为导出功能，而非仅因测试方便