结构体字段的零值是明确默认值而非未初始化，如int为0、string为空、map/slice为nil；需显式初始化引用类型字段以防panic。
结构体字段的零值不是“未初始化”，而是明确的默认值
Go 中声明但未显式赋值的结构体变量，所有字段都会被赋予对应类型的零值——这不是“随机值”或“内存残留”，而是语言强制保证的行为。比如 int 是 0，string 是 ""，*int 是 nil，map[string]int 是 nil，[]byte 是 nil（不是空切片 []byte{}）。
容易踩的坑：
- 误把
nil map当成空map，直接myStruct.Data["key"] = 1会 panic：assignment to entry in nil map - 误把
nil slice当成长度为 0 的切片，调用len()或cap()没问题，但append()前不初始化会导致后续逻辑错乱（比如忘了检查是否为nil就直接遍历） - 嵌套结构体字段不会自动初始化内部结构体，而是整个字段为对应结构体类型的零值（即各字段再递归取零值）
new() 和 &T{} 都产生零值结构体，但语义和使用场景不同
new(T) 返回 *T，内容全零；&T{} 也返回 *T，内容同样全零。表面效果一样，但背后意图不同。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
&T{}表示“我要一个新结构体指针”，尤其适合带字段初始化：&User{Name: "Alice", Age: 0}（未写的字段仍为零值） - 避免用
new(User)，它无法指定任何字段，可读性差，且容易让人误以为它做了“分配+构造”之类额外工作（其实没有） - 如果只是需要零值指针且不打算初始化字段，
&T{}更直观，Go 官方代码和主流库也基本不用new构造结构体
零值结构体可能引发隐性 bug：map/slice/channel/func/interface 字段需手动初始化
这些类型在零值时都是 nil，不能直接使用。结构体本身是零值没问题，但字段一旦是这些类型，就很容易在后续操作中 panic 或逻辑跳过。
常见错误现象：
-
json.Unmarshal([]byte(`{"items":[1,2]}`), &s)后，s.Items是nil而非空切片，导致for range s.Items不执行（而不是遍历 0 次） -
s.ConfigMap["timeout"]panic，因为s.ConfigMap是零值nil map，没做s.ConfigMap = make(map[string]string) - 方法接收者是值类型时，对
nil切片字段调用append不会修改原字段（因为传的是副本），但开发者常误以为会生效
推荐做法：在结构体定义后、使用前，显式初始化这类字段，或用构造函数封装：
func NewService() *Service {
return &Service{
Cache: make(map[string]*Item),
Tasks: make(chan Task, 16),
Handlers: []Handler{},
Logger: log.Default(),
}
}
嵌套结构体与匿名字段的零值继承规则很直接，但别指望“智能合并”
嵌套结构体字段的零值，就是其类型定义的零值；匿名字段（内嵌）也一样——它只是把字段“提上来”，不改变初始化逻辑。
例如：
type Config struct {
Timeout int
LogMode string
}
type Server struct {
Config // 匿名字段
Addr string
}
那么 var s Server 中，s.Timeout 是 0，s.LogMode 是 ""，s.Addr 是 ""。看起来像“自动继承”，其实是 Go 在初始化 Server 时，对每个字段（包括匿名字段）分别执行零值填充。
注意点：
- 如果嵌套结构体里有
nilmap/slice，外层结构体零值后它们仍是nil，不会自动变成非nil - 匿名字段不能省略初始化：比如
Server{Addr: "localhost"}中，Config字段仍为零值，不会从其他地方“自动补全” - 组合多个匿名字段时，字段名冲突不会报错，但访问时会编译失败（歧义），这和零值无关，但常在零值调试阶段暴露出来
零值本身很可靠，麻烦的是人总想当然地认为“nil slice 就等于空 slice”或者“没初始化 map 就能直接写”，而 Go 偏偏不做这种隐式兜底。写结构体时，凡是可能被直接使用的引用类型字段，初始化动作最好写死，别靠运气。
