Go语言为什么强调值语义_Golang语言设计哲学说明

go语言一切皆值传递，复制整块内存或含指针的header；slice/map/chan等通过header共享底层数据，需注意append不返回新header导致调用方无法感知扩容。

Go 语言没有“值语义”这个独立设计概念，它只有一条铁律：一切皆值传递。所谓“值语义”是外界对这条规则的误读或简化表述，真正要理解的，是 Go 如何用统一的值复制机制，配合底层指针封装，达成高效、可控、可预测的数据行为。

函数传参时，int 和 Struct{} 都复制，但 []byte 看起来像“传引用”？

是的，但本质仍是值传递——只是复制的是“头信息”（header），不是底层数组。

• int、String、[3]int、struct{ x, y int }：整块内存拷贝，修改参数不影响原值
• []byte、map[string]int、chan int：复制的是含指针的 header（如 slice 的 data、len、cap），所以 append 可能影响原 slice 的底层数组（若未扩容），但改 s[0] = 1 会反映到原 slice；而重赋值 s = append(s, 1) 后再改，就不会影响原 slice —— 因为 header 已被替换
• 常见错误：在函数里对 map 做 delete 或赋值 key，能生效；但对 slice 做 append 后不返回新 slice，调用方收不到扩容后的新 header，导致后续操作 panic 或逻辑错乱

什么时候必须用 *T 而不是 T？

不是为了“性能”，而是为了“修改意图明确”和“避免意外拷贝”。

• 结构体较大（比如 > 64 字节）且频繁传参时，用指针可省拷贝——但这只是副作用，不是设计动因
• 需要函数内修改调用方持有的原始值时，必须传指针：比如 func reset(v *int) { *v = 0 }
• 结构体含不可复制字段（如 sync.Mutex）时，T 无法作为 map key 或参与比较，只能用 *T
• 接口值中保存的是 T 还是 *T，决定了方法集：只有 *T 实现了某接口方法，那 T 类型变量就不能直接赋给该接口变量（会编译报错 cannot use t (type T) as type Interface in assignment: T does not implement Interface）

make 出来的 slice 和 new 出来的 *[]T 有什么区别？

根本不在一个抽象层：一个是创建带底层数组的 slice header，另一个是分配一个指向 slice header 的指针，且该 header 初始为零值（nil）。

立即学习“go语言免费学习笔记（深入）”；

• s := make([]int, 3) → s 是可用 slice，len(s)==3，可直接读写 s[0]
• p := new([]int) → p 是 *[]int，但 *p 是 nil slice，len(*p) panic，必须先 *p = make([]int, 3) 才能用
• 几乎没人用 new([]T)，因为 slice 本身已是轻量 header；需要“可变长度容器”就直接用 []T，需要“共享容器头”就传 []T 或 *[]T，但后者极少必要
• 容易踩的坑：把 new([]int) 当成 make([]int, 0) 用，结果一读就 panic

最常被忽略的一点：Go 的“值传递”不是性能妥协，而是心智模型锚点——你永远知道某个变量是独立副本还是共享底层数据，只要看它的类型是否属于那五种 header 类型（slice/map/chan/func/string）。一旦混用指针与值、或误以为 map/slice 是“引用类型”，bug 就藏在 header 复制与底层数组共享的边界上。