不安全但可控——仅限测试中使用，需确保传入指针、逐层解引用，避免依赖字段布局；reflect.deepequal跳过私有字段，比对需手动遍历；优先用导出字段或测试专用构造函数替代反射。
go 测试里用 reflect 读私有字段，真的安全吗？
不安全，但可控——前提是只在测试中用，且不依赖字段布局或类型细节。Go 的私有字段（首字母小写）在运行时完全可反射访问，reflect.Value.FieldByName 能拿到，reflect.Value.interface() 也能转出值，但一旦字段被内联、重命名或结构体加了新字段，测试就可能悄无声息地失效。
- 仅限
testing包内使用，绝不放进生产代码 - 避免对字段做深比较（比如递归反射比对），优先用显式字段名 + 类型断言
- 如果结构体用了
json标签或嵌套指针，reflect.Value.Elem()和reflect.Indirect()容易漏一层，先打日志看reflect.typeof(v).kind()
reflect.Value.FieldByName 找不到私有字段？检查导出状态和接收者
找不到不是因为“私有”，而是因为传入的值不是地址或没解引用到位。Go 反射要求：要修改或读取未导出字段，必须从指针开始；直接传 Struct 值会 panic 或返回零值。
- 错误写法：
reflect.ValueOf(myStruct).FieldByName("name")→ 返回无效值（!v.IsValid()） - 正确写法：
reflect.ValueOf(&myStruct).Elem().FieldByName("name") - 若字段是嵌套结构体（如
user.profile.age），不能链式调用FieldByName，得逐层Elem()或Indirect()
用 reflect.DeepEqual 比对含私有字段的 struct，为什么总失败？
因为 reflect.DeepEqual 本身尊重导出性：它只比较导出字段，所有小写字段被跳过。这不是 bug，是设计使然——它模拟的是“外部可见的相等性”。想比私有字段，必须手动展开。
- 别用
reflect.DeepEqual(a, b)直接比两个 struct 实例 - 改用：先
reflect.ValueOf(&a).Elem()和reflect.ValueOf(&b).Elem()，再遍历NumField()，对每个Field(i)单独Interface()后比 - 注意：
time.Time、map、func字段不能直接Interface()后比，需特殊处理
替代方案：为什么有时该放弃反射，改用导出字段或测试友好的构造函数？
反射让测试脆弱，尤其当结构体字段语义重要（比如 isVerified bool）、或字段类型频繁变化（如从 int 改成 int64）。这时候硬反射不如改一点设计。
立即学习“go语言免费学习笔记（深入）”；
- 给 struct 加一个测试专用方法，如
ForTest() map[String]interface{}，返回所有字段（包括私有）的键值对 - 把关键私有状态抽成小 struct 并导出，比如
type UserState struct { IsBanned bool }，原 struct 内嵌它 - 用函数选项模式构造对象，测试时通过
WithIsVerified(true)显式控制，比事后反射读更可靠
反射不是黑魔法，它只是绕过了编译器检查——而 Go 的测试稳定性，恰恰建立在编译器能帮你守住的边界上。越想“非侵入”，越得清楚自己绕开了哪道门，以及门后有没有锁。