reflect.New只接受非指针类型，传入**T等多级指针类型会panic；正确做法是对最内层类型T调用New，再链式Addr()获取多级指针，同时缓存Type和字段索引以避免重复解析与线性搜索。
reflect.New 创建多级指针时为什么 panic？
常见错误是传入 reflect.TypeOf(&T{}) 给 reflect.New，结果得到 **T 类型，再 New 一次就变成 ***T——Go 不允许对指针类型再次调用 New。错误现象是：panic: reflect: New(nil) 或 reflect: call of reflect.New on ptr Type。
根本原因： reflect.New 只接受非指针类型的 reflect.Type（即 Kind() 必须是 Struct、Int、String 等，不能是 Ptr）。
- 正确做法：用
reflect.TypeOf(T{}).Elem()不行（T{}不是接口），应统一用reflect.TypeOf((*T)(nil)).Elem()获取T的reflect.Type - 若已有
interface{}值 v，先rv := reflect.ValueOf(v)，再根据rv.Kind()判断：若是Ptr，需rv.Elem().Type()；若是Interface，得先rv.Elem()再取Type() - 多级指针如
***T，不能靠反复New实现；必须明确目标层级，只对最内层类型（T）调用New，再逐层取地址
多级指针对象创建的两种安全路径
要得到 ***T，不是 “New 三次”，而是 “New 一次 + 两次取地址”。运行时开销集中在第一次 New，后续 Addr() 是纯指针运算，零分配。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 路径一（推荐）：从
T开始，用reflect.New(tType)得到*T，再链式调用.Addr().Addr()得到**T和***T - 路径二（更可控）：用
unsafe.Pointer手动计算偏移——但仅当 T 是固定布局且无 GC 移动风险时才考虑；普通业务场景没必要 - 别用
reflect.NewAt模拟多级指针：它要求你提供已分配的内存地址，而多级指针的中间层（如 **T）本身就需要合法堆地址，容易引发 dangling pointer
缓存类型信息能省多少开销？
实测在高频创建（如每秒 10 万次）场景下，不缓存 reflect.TypeOf 会导致 CPU 时间上升 3–4 倍，GC 分配量翻倍。关键不是 New 本身慢，而是每次都要重新解析类型结构。
立即学习“go语言免费学习笔记（深入）”；
- 缓存 key 必须用
uintptr(unsafe.Pointer(t))，不是t.String()（匿名 struct 失效）或t.PkgPath() + "." + t.Name()（模块多版本冲突） - 缓存 value 推荐存
reflect.Type+ 预算好的字段偏移数组（如[]uintptr），而不是reflect.Value（不可比较、每次新建） - 不要用
sync.Map存类型缓存：读多写少，普通map[uintptr]typeInfo+sync.RWMutex更快；初始化可用sync.Once配合惰性填充
真正要避开的性能陷阱
很多人以为“用了缓存就万事大吉”，但多级指针场景下，真正的瓶颈往往藏在后续字段访问里——比如你创建了 ***User，接着用 Value.Elem().Elem().Elem().FieldByName("Name")，这会触发三次线性搜索（FieldByName 是 O(n)），比单次反射 New 还贵。
- 字段访问务必转成索引：提前缓存
map[uintptr]int记录字段名到Index的映射，用Field(i)替代FieldByName - 如果字段逻辑复杂（比如带 tag 解析、条件跳过），直接预生成闭包：输入
interface{}，输出string，内部用unsafe.Offsetof+ 强制类型转换，彻底绕过反射 - 多级解引用本身不慢，但每次
Elem()都要检查可寻址性；确保原始reflect.Value来自reflect.New或&v，而非不可寻址的字面量
