reflect.ValueOf 直接调用 panic 是因传入 nil 指针或未导出字段导致值无效，须先检查 v.IsValid() 和 v.CanInterface()；结构体字段跳过需手动解析 tag（如 cache:"skip"）；hash 写入须保证顺序确定性，避免 map 无序遍历；高频场景应预缓存反射元数据以提升性能。
为什么 reflect.ValueOf 直接调用会 panic？
因为传入 nil 指针或未导出字段时，reflect.ValueOf 返回的值无法取地址或读取内容，后续调用 .Interface() 或 .String() 就崩了。
- 常见错误现象：
panic: reflect: call of reflect.Value.Interface on zero Value - 必须先检查
v.IsValid()和v.CanInterface()，尤其处理结构体嵌套时，某一层可能为空 - 如果参数是
*T且为 nil，reflect.ValueOf(ptr).Elem()会直接 panic，得先if v.Kind() == reflect.Ptr && v.IsNil() { ... } - 示例：传入
var u *User = nil，不能直接v.Elem().FieldByName("ID")
结构体字段怎么跳过不参与 Key 计算？
Go 反射本身不识别 tag 语义，得手动解析 struct 的 reflect.StructField.Tag，再决定是否忽略。
- 使用场景：比如
ID字段带json:"-" cache:"skip"，就该跳过 - 别只看
json:"-"—— 不同包对 tag 解析逻辑不同，缓存 key 生成器应约定统一 tag，如cache:"skip" - 注意 tag 值是字符串，要调用
field.Tag.Get("cache") == "skip"，不是strings.Contains模糊匹配 - 嵌套结构体字段也要递归检查 tag，否则深层字段可能意外参与哈希
hash.Hash 写入顺序错乱会导致 Key 不一致
反射遍历 struct 字段默认按内存布局顺序（即定义顺序），但若字段被重排、加了 //go:notinheap 或用了 unsafe，顺序可能变；更常见的是 map 遍历无序，一不留神就把 map 值当结构体字段塞进 hash 了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误现象：同一输入，两次生成的 key 不一样，缓存命中率骤降
- 永远不要用
for k := range mapVal直接写入 hash —— 改成keys := make([]string, 0, len(mapVal)); for k := range mapVal { keys = append(keys, k) }; sort.Strings(keys) - struct 字段遍历虽有序，但若混入 interface{} 值（比如字段类型是
interface{}），实际值可能是 map/slice，就得单独判断并强制排序 - 建议在写入 hash 前统一转成确定性序列：比如先写字段名，再写字段值类型，最后写值的规范表示（如 time.Time 转 RFC3339 字符串）
性能陷阱：每次生成 key 都做完整反射太慢
反射开销集中在 reflect.TypeOf 和反复调用 FieldByName，尤其高频缓存场景下，能缓存的元数据绝不要重复计算。
立即学习“go语言免费学习笔记（深入）”；
- 把
reflect.Type对应的字段索引、是否跳过、序列化方式等预计算好，存在sync.Map里，key 是t.String() - 别对每个请求都调用
reflect.ValueOf(x).Kind() == reflect.Struct—— 类型判断可提前做，用类型断言或switch x.(type)分流 - 小结构体（[]byte 或大字符串字段，记得用
sha256.Sum256替代逐字节hash.Write，减少内存拷贝 - 测试时用
benchstat对比：纯反射 vs 类型专用函数，差距常在 3x~10x
最麻烦的其实是 interface{} 值的展开深度和循环引用检测——没做这层，遇到自引用 struct 就无限递归。这个点容易被忽略，但线上一跑就卡死 goroutine。
