reflect.New创建结构体比字面量慢15–30倍，实测5字段结构体为48 ns/op（16 B/op堆分配） vs 字面量2.1 ns/op（0 B/op栈分配），主因是运行时查表、堆分配、类型擦除及无法内联。
reflect.New 创建结构体比字面量慢多少？
直接结论：reflect.New 创建结构体实例，比原生字面量初始化慢 15–30 倍，且伴随明显堆分配。这不是“有点慢”，而是热点路径上必须规避的级别。
原因在于 reflect.New 必须在运行时查表获取 reflect.Type，再调用底层内存分配器（类似 malloc），最后做类型擦除包装——整个过程无法被编译器内联或优化。而 User{Name: "a", Age: 20} 是纯栈分配、零间接跳转的机器码。
实测一个 5 字段结构体，在 Go 1.26 下：
- 字面量初始化：
2.1 ns/op，0 B/op -
reflect.New(t).Elem().Interface()：48 ns/op，16 B/op（逃逸到堆）
注意：若结构体含 slice、map 或嵌套 struct，反射开销会非线性放大，因为每个子项都要重复类型解析和分配。
立即学习“go语言免费学习笔记（深入）”；
为什么 Elem().Interface() 是性能黑洞？
这段链式调用：reflect.New(t).Elem().Interface() 看似简洁，实际每步都在制造开销：
-
reflect.New(t)：触发一次堆分配 + 类型元数据查找 -
.Elem()：返回新分配对象的reflect.Value包装，额外封装开销 -
.Interface()：强制类型擦除，生成 interface{}，触发接口字典查找和值拷贝
更糟的是，如果后续还要对这个实例做字段赋值（比如 v.FieldByName("Name").SetString(...)），每次 FieldByName 都要线性遍历字段名字符串匹配，SetString 又触发一次接口断言和内存拷贝——这些在字面量里全是编译期常量折叠。
替代写法（无反射）：u := User{}; u.Name = "x"; u.Age = 10 —— 所有操作都在栈上，无逃逸，可被内联。
缓存 reflect.Type 能省多少？
缓存 reflect.Type 可以消除重复的类型查找，但对整体性能提升有限——它只解决“查表”那一步，不解决分配、包装、擦除这三座大山。
实测对比（同一结构体反复创建）：
- 每次调用都
reflect.TypeOf(&User{})：62 ns/op - 提前
var userType = reflect.TypeOf(&User{}).Elem()缓存：48 ns/op
省了约 22%，但绝对值仍远高于字面量。而且缓存本身需全局变量或 sync.Once 初始化，引入并发安全或初始化顺序问题。真正值得缓存的是「校验规则」或「字段映射表」这类高复用、低变更的数据，而不是 Type 本身。
如果你真需要动态结构体创建，优先考虑代码生成（如 go:generate 为每个结构体生成工厂函数），而非运行时反射。
什么场景下还不得不反射创建？
只有两类真实需求绕不开：配置驱动的插件系统（如从 YAML 读出结构体名，再实例化）和 泛型尚不支持的旧版 Go 兼容层（Go
- ORM：用
sql.Scanner接口 + 指针接收，避免实例化中间 struct - API 绑定：用
json.Unmarshal直接进目标 struct，它内部虽用反射，但做了深度优化（如字段名哈希缓存） - Mock：用接口抽象 + 实际类型组合，而非反射构造
记住：反射创建结构体不是“通用方案”，而是“最后手段”。它的代价不是 CPU 时间数字，而是你再也无法靠 go tool trace 看清内存生命周期，也无法用 go vet 检查字段赋值是否遗漏——这些隐性成本，比 ns/op 更难修复。
