Go语言为何注重值语义？

Go语言的核心设计哲学是“一切皆值传递”，所谓“值语义”实为外界对这一铁律的误读；它通过统一的值复制机制——对基础类型和小结构体整块拷贝，对slice/map/chan/string等则复制含指针的轻量header——在保证行为可预测、心智模型清晰的同时，巧妙实现底层数据共享与高效操作；真正关键在于理解五种header类型的行为边界：它们看似“传引用”，实为值传递header，而append不返回新header、map可原地修改但slice扩容需显式返回、大结构体传指针本质是为语义明确而非性能优化——这些细节恰恰构成了Go健壮、简洁又易踩坑的底层逻辑。

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）。

• 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 复制与底层数组共享的边界上。

今天关于《Go语言为何注重值语义？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！