私有结构体不能在测试文件中直接实例化，因go包级访问控制限制非导出类型仅限本包使用；测试必须通过导出的构造函数（如newuser）获取实例，且构造函数应支持参数化、最小校验与测试专用变体。
私有结构体为什么不能在测试文件里直接 new
Go 的包级访问控制很严格：结构体字段或类型本身如果以小写字母开头，就只能在定义它的包内使用。测试文件（xxx_test.go）属于另一个包（哪怕同名加 _test 后缀），所以连 &MyStruct{} 都会报 cannot refer to unexported field or method。
常见错误现象：
— 测试里写 u := &user{ID: 1}，编译失败
— 尝试用反射 reflect.New() 创建实例，但字段无法赋值，后续逻辑空指针 panic
- 必须通过导出的构造函数（如
NewUser()）获取实例，这是唯一安全路径 - 构造函数内部可以自由访问私有字段，测试只需依赖它返回的完整对象
- 不要试图绕过访问控制——比如把结构体改成导出、或用
unsafe，这会让封装失效且难以维护
导出构造函数怎么写才适合测试
构造函数不是越简单越好，关键要覆盖测试中需要控制的初始化维度。比如一个带验证逻辑的私有结构体，直接暴露字段初始化反而容易让测试用例写出非法状态。
使用场景：
— 单元测试需构造合法但边界化的实例（如空字符串、负数 ID）
— 模拟不同业务状态（Active / Inactive）
— 避免测试因内部字段默认零值而偶然通过
立即学习“go语言免费学习笔记（深入）”；
- 优先用参数化构造函数，例如
NewUser(id int, name string, active bool)，而非无参NewUser() - 若结构体字段多或可选，考虑用选项模式（
func WithName(name string) Option），但注意别过度设计——3 个以内字段直接参数更清晰 - 构造函数应做最小必要校验（如
id > 0），避免把业务规则硬编码进初始化逻辑；测试需要非法状态时，应由构造函数提供绕过校验的变体（如NewUserUnsafe()并加注释说明仅限测试）
测试里调用构造函数的典型陷阱
看似只是调个函数，但实际容易踩几个隐蔽坑：字段默认值干扰断言、时间字段未显式设置导致 flaky test、构造函数自身有副作用（如发 HTTP 请求）。
常见错误现象：
— 测试断言 u.CreatedAt.IsZero() 偶尔失败
— 并行测试中多个 goroutine 共享同一构造函数创建的资源（如全局 map）
— NewUser() 内部调了 time.Now()，结果断言时间精度失败
- 永远显式传入时间字段，不要依赖构造函数里的
time.Now()；测试中用固定时间值（如testTime := time.Unix(123, 0)） - 确保构造函数是纯函数：无全局状态修改、无 I/O、无随机性；如有必要，把外部依赖抽成参数（如
clock Clock接口） - 在测试文件中 import 被测包时，确认是导入主包路径（如
"myapp/user"），不是"myapp/user_test"——后者会导致循环导入或包隔离失效
不导出结构体但想测字段逻辑怎么办
有时你并不想初始化整个结构体，只是想验证某个私有方法对字段的计算是否正确，比如 u.calculateScore()。这时候强行走构造函数反而绕远路。
性能 / 兼容性影响：
— 反射读取私有字段（reflect.Value.FieldByName("score")）可行但慢，且 Go 1.19+ 对非导出字段的反射访问更严格
— 为测试加 getter 方法（Score()）会污染公共 API
- 最佳实践是把核心计算逻辑拆到独立的、导出的纯函数里，例如
CalculateScore(base, bonus int) int，然后在结构体方法中调用它；测试直接喂输入、断言输出 - 如果逻辑强耦合字段状态，可在结构体所在包内建一个
internal_test.go文件（不加_test后缀），和结构体同包，就能直接访问私有字段——但仅限该包自己的测试逻辑，外部测试仍走构造函数 - 别为了测试妥协封装：宁可多写一行函数拆分，也不要开放不该暴露的字段或方法
真正难的不是怎么初始化，而是判断哪些字段/行为该被测试直接触达——这取决于你有没有把「状态」和「逻辑」分开设计。没分清的话，再花哨的构造技巧也救不了测试脆弱性。
