黑盒测试需将xxx_test.go置于被测包同级目录，声明package xxx_test并显式import模块路径；白盒测试则须同目录同包名，不import即可访问未导出标识符。
Go 黑盒测试怎么写：不 import 被测包的 xxx_test.go
黑盒测试在 Go 里就是「只通过公开 API 交互，不依赖内部结构」的测试，核心是隔离——测试文件不能和被测包同名，也不能 import 它的内部路径。
常见错误现象：import cycle not allowed 或测试跑不起来，往往是因为写了 import "./mylib" 或把测试文件放在了被测包目录下却用了同名包声明。
- 测试文件必须命名为
xxx_test.go（下划线 + test 后缀） - 包声明必须是
package xxx_test，且不能和被测包名一致（比如被测是package mylib，测试就得是package mylib_test） - 测试文件放在和被测包**同一级目录**，不是子目录；否则
go test可能找不到 - 要调用被测函数，必须通过
import "your/module/path/mylib"显式引入，不能用相对路径或本地 import
示例：被测代码在 mylib/sum.go，黑盒测试就放同一级的 mylib/sum_test.go，开头写 package mylib_test，然后 import "example.com/mylib" 再调用 mylib.Sum()。
Go 白盒测试怎么写：同包内测，直接访问未导出标识符
白盒测试本质是「换了个文件，但还在同一个包里」，所以能直接用未导出函数、变量、字段——这是 Go 测试机制的特许权，不是 hack。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：想测一个 func helper() {} 却报 undefined: helper，大概率是包名没对齐或路径错了。
- 测试文件也叫
xxx_test.go，但包声明必须和被测包**完全一致**，比如被测是package mylib，测试也得是package mylib - 测试文件必须和被测源码在**同一目录**（不能在子目录，也不能跨模块路径）
- 不需要 import 被测包——它就是你自己的包
-
go test会自动把*_test.go和同目录非_test.go文件一起编译进同一个包，所以未导出名天然可见
示例：mylib/sum.go 和 mylib/sum_internal_test.go 都声明 package mylib，后者就能直接调用 helperSum()（未导出函数）。
_test.go 命名和位置踩坑清单
Go 的 test 机制对文件名和位置极其敏感，错一个字符或一层目录就失效。
- 文件名必须以
_test.go结尾，test_.go、xxx.test.go、xxx_test（缺 .go）都不行 - 测试文件不能放在
internal/、vendor/或以_或.开头的目录里，go test默认跳过 - 如果模块启用了 Go Modules，测试文件里的 import 路径必须和
go.mod里定义的 module path 一致，不能用./xxx - 运行
go test -v时如果没看到任何测试函数执行，先用go list -f '{{.TestGoFiles}}' ./...确认哪些文件被识别为测试文件
黑盒 vs 白盒：什么时候该用哪个
不是风格偏好问题，而是接口稳定性和测试目标决定的。
- 测公共 API 行为、兼容性、文档示例是否有效 → 用黑盒；这样重构内部实现时，测试不会误挂
- 测边界逻辑、错误分支、未导出辅助函数、初始化副作用 → 用白盒；否则只能靠输出反推，难写也难懂
- 性能敏感路径（如高频工具函数）建议白盒，避免 import 开销和间接调用；但要注意：白盒测试会随内部变更频繁失败，别把它当集成稳定性指标
- 如果被测包有大量未导出状态（如全局变量、sync.Once），白盒几乎是唯一可靠方式；黑盒很难触发或断言这类状态
真正容易被忽略的是：很多人把白盒当成“省事写法”，结果把本该验证行为的测试，写成了对实现细节的硬编码快照——比如断言某个私有 map 的长度，而不是断言最终输出是否符合契约。这种测试比不写还危险。
