应优先用 &T{}，仅当需动态生成未知类型的零值用于比较、占位或测试桩时才用 reflect.Zero；reflect.New 用于后续需修改字段或传参给 *T 函数的场景。
什么时候该用 reflect.Zero 而不是 reflect.New
reflect.Zero 返回的是**零值本身**（非指针），而 reflect.New 返回的是指向零值的**指针**。两者语义完全不同，选错会导致后续无法赋值或 panic。
常见误用场景：想初始化一个结构体变量并修改其字段，却用了 reflect.Zero(t) —— 它返回的是不可寻址的只读值，.FieldByName("X").Set() 会直接 panic。
- 用
reflect.Zero的合理场景：
– 需要“纯零值字面量”做比较（比如判断某字段是否仍为零）
– 构造 map/slice 的零值默认值（map[string]int{}对应reflect.Zero(reflect.MapOf(...))）
– 序列化/模板填充时提供安全兜底值（不打算修改，只读使用） - 用
reflect.New的场景：
– 后续要调用.Elem().FieldByName().Set()动态设字段
– 需要传给接收*T的函数
– 模拟&T{}的行为（即获得可修改的指针）
reflect.Zero 对结构体字段的零值表现是正常的，不是 bug
执行 reflect.Zero(reflect.TypeOf(User{})).Interface() 得到的 User{Id: 0, No: nil, Identity: "", Head: url.URL{}}，所有字段都按 Go 类型系统规则填了对应零值。这不是初始化失败，而是设计如此。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 看到
No: nil就以为“字段没创建”，其实*string的零值就是nil，和var s *string效果一致 - 看到
Head: { <nil> }</nil>就怀疑url.URL没实例化，但用%#v打印会显示完整字段，证明结构体已存在且各字段均为零值 - 对私有字段（小写首字母）调用
reflect.Zero没问题，但后续无法用反射修改它——因为reflect.Zero本身不涉及可设置性，只是生成值
嵌套结构体 + reflect.Zero 的典型误用
当结构体字段是另一个结构体（如 Config struct{ Timeout int }），reflect.Zero 会递归生成整个嵌套零值。但若字段是接口或指针类型（如 Logger log.Logger 或 DB *sql.DB），它的零值分别是 nil 接口和 nil 指针——这在运行时可能触发 panic。
所以不能依赖 reflect.Zero 替代显式初始化逻辑：
- 含
map/slice/chan字段？reflect.Zero给的是nil，不是make(...)后的空容器 - 含自定义类型（如
url.URL、time.Time）？它们的零值合法，但业务上可能不允许（比如要求Timeout > 0） - 字段带
defaulttag？reflect.Zero完全忽略标签，它只管类型定义的零值
替代方案：优先用 &T{}，reflect.Zero 是边界工具
日常开发中，95% 的结构体初始化需求，直接写 &User{} 或 &User{Name: "x"} 更清晰、安全、高效。reflect.Zero 只应在以下情况考虑：
- 你持有
reflect.Type但不知道具体类型名（比如泛型擦除后、插件系统、配置反序列化中间层） - 需要统一生成某类类型的零值用于比较或占位（如构建测试桩、mock 默认响应）
- 封装一个通用的 “零值构造器” 工具函数，且明确接受其局限性（不处理深层初始化、不读标签、不校验业务约束）
真正棘手的点不在 reflect.Zero 本身，而在于混淆了「类型零值」和「业务有效默认值」——后者永远需要显式逻辑，反射帮不上忙。
