反射与unsafe非同一维度工具：反射提供类型安全的动态操作，unsafe执行无检查的内存地址操作；性能优化需先定位瓶颈，而非盲目切换。
反射和 unsafe 不是同一维度的工具，谈“性能对比”容易误导——反射做的是类型安全的动态操作，unsafe 做的是无检查的内存地址操作；真要提速，得先明确你卡在哪一环，而不是直接切到 unsafe。
FieldByName 为什么比 Field(i) 慢 17 倍
FieldByName 内部是线性遍历所有字段名做字符串比较，100 字段就要比 100 次；而 Field(i) 是数组下标访问，常数时间。这不是反射本身慢，是设计上为灵活性牺牲了热路径性能。
- 别在循环里反复调用
reflect.Value.FieldByName("Name")，尤其在 HTTP handler 或数据库映射层 - 缓存字段索引：用
reflect.TypeOf(v).FieldByName("Name").Index预算一次，后续走v.Field(index) - 字段名拼写错误时，
FieldByName返回零值reflect.Value，CanSet()为 false，不 panic 但逻辑静默失效
unsafe.Offsetof 能替代 FieldByName 吗
能，但只适用于字段布局稳定、且你有合法访问入口的场景。unsafe 不认识字段名，它只认偏移量；而偏移量必须通过 unsafe.Offsetof(T{}.FieldName) 获取——这意味着字段名必须能在当前包被合法引用。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 私有字段（小写开头）无法在外部包中写
T{}.fieldName，所以unsafe.Offsetof在多数跨包场景下根本用不了 - 结构体加字段、改顺序、启用
//go:notinheap，都可能让偏移量失效，运行时崩溃而非编译报错 - Go 1.20+ 推荐用
unsafe.String(unsafe.SliceData(b), len(b))替代老式*(*string)(unsafe.Pointer(&b))，前者经标准库验证，后者易因 slice header 变动出错
reflect.Value.UnsafeAddr() 的唯一安全用法
只有当 reflect.Value.CanAddr() == true 时，.UnsafeAddr() 才返回有效地址；它不是用来“绕过反射”，而是为零拷贝序列化或批量字段操作提供可寻址入口。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
reflect.ValueOf(myStruct).UnsafeAddr()→ 返回的是栈上临时值地址，GC 后悬垂 - 正确写法：
reflect.ValueOf(&myStruct).Elem().Field(0).UnsafeAddr()→ 确保底层内存由变量本身持有 - 对
[]byte拿底层数组地址，必须取reflect.ValueOf(&s).Elem().Field(0).UnsafeAddr()（字段 0 是 data pointer），不能直接对 slice 值调.UnsafeAddr()
真正难的不是选反射还是 unsafe，而是判断哪部分值得优化：95% 的性能瓶颈不在字段访问，而在 IO、锁、GC 分配或网络延迟；盲目上 unsafe，往往换来更难复现的 crash，而不是更快的响应。
