go中值类型的零值是确定的全0字节清零，非未定义或随机值；int为0、bool为false、string为""、struct和数组各字段/元素递归应用零值规则，new与var均触发内存清零，make仅用于slice/map/chan。
Go中值类型的零值不是“空”，而是确定的二进制填充
Go里int、struct、[3]int这类值类型变量声明但未显式赋值时，内存里真真切切填的是全0字节——不是“未定义”，也不是“随机残留”，是runtime在分配栈或堆内存时直接用memset清零。这点和C不同，也和某些动态语言的“undefined”语义完全相反。
常见错误现象：fmt.Printf("%p", &x)看到地址有效，就以为x可安全读；其实只要类型含指针字段（比如struct{ p *int }），零值的p就是nil，解引用必panic。
- 所有内置数值类型零值：0（
int）、0.0（float64）、false（bool） - 字符串零值：
""，底层string结构体两个字段都是0（len=0, ptr=nil） - 数组零值：每个元素递归应用零值规则，
[2][3]int{}→ 内存连续6个0 - 结构体零值：字段按声明顺序逐个取零值，不跳过任何字段
new()和var声明的零值行为完全一致，但make()只用于引用类型
new(T)返回*T，var x T声明T值，两者都产生零值，且底层都是清零内存。但make([]int, 5)这种不能用new()替代——new([]int)返回的是[]int零值（即nil切片），不是长度为5的切片。
使用场景差异：
立即学习“go语言免费学习笔记（深入）”；
- 需要立即获得非nil指针时用
new(T)，比如http.HandlerFunc接收*bytes.Buffer参数 - 声明局部变量优先用
var x T或短变量声明x := T{}，语义更直白 -
make()专用于slice、map、chan三种引用类型，它做两件事：分配底层数据结构 + 初始化（如slice的len/cap、map的哈希表头）
性能影响：对大结构体，var x BigStruct会清零整个内存块，而new(BigStruct)同样要清零——没有省事的捷径。如果真想跳过初始化，得用unsafe手动分配+memclr绕过，但几乎没正当理由这么做。
零值初始化在逃逸分析和GC压力上的隐性成本
看似无害的零值，在编译器决定变量是否逃逸时会起作用。例如func f() *bytes.Buffer { var b bytes.Buffer; return &b }，因为b被取地址并返回，它必须逃逸到堆上——而堆分配必然触发内存清零，还增加GC扫描负担。
容易踩的坑：
- 在循环内反复声明大数组（如
[1024]byte），每次迭代都清零1KB，CPU cache压力明显 - 结构体字段含
sync.Mutex：零值是有效锁，但sync.Mutex零值内部有state和sema字段，清零本身开销小，误以为“没初始化就不能用”是错的——它本来就能直接Lock() - 接口类型变量的零值是
nil，但它的底层值如果是大结构体，赋值给接口时会拷贝整个值，此时零值初始化成本就被放大了
结构体字段顺序影响零值内存布局和填充字节
Go struct的字段排列不是按声明顺序物理存储的，而是按大小升序重排（除了第一个字段保持原位），目的是减少padding。这意味着即使两个结构体字段完全相同，仅顺序不同，它们的零值内存表现就可能不一样——尤其是涉及指针/uintptr混排时。
实操建议：
- 用
unsafe.Sizeof和unsafe.Offsetof验证实际布局，别靠肉眼猜 - 把大字段（如
[1000]byte）放前面，小字段（bool、int8）放后面，能显著减少padding，零值清零范围更小 - 嵌入字段的零值会完整展开，比如
type A struct{ B; int }中B若含4个int64，那A{}零值就得清零32+8=40字节，而不是只清外层
真正难处理的从来不是“怎么初始化”，而是初始化之后没人检查字段是否真的需要零值——比如一个本该由构造函数设置的id uint64，零值0可能变成合法ID，埋下数据一致性隐患。
