Go 值类型函数调用默认按值传递，修改形参不影响实参；大结构体传值有性能开销；字符串和切片传参拷贝头部但共享底层数组；方法集与接收者类型影响接口实现。
Go 的值类型（如 int、string、struct、[3]int 等）在函数调用时默认按值传递，看似简单，但实际开发中常因忽略“拷贝语义”引发隐蔽问题。核心误区不是“传值慢”，而是误以为修改形参会影响实参，或对底层拷贝成本缺乏感知。
修改形参不会影响原始变量
这是最常见误解：把值类型变量传入函数后，在函数内对其赋值或调用方法，原变量完全不受影响。
例如：
type User struct {Name string} func changeName(u User) {u.Name = "Alice"} u := User{Name: "Bob"} changeName(u) // u.Name 仍是 "Bob"，未变解决办法很直接：需要修改原值时，传指针 *User；仅读取时，传值更安全、更符合 Go 惯例。
大结构体传值可能带来意外性能开销
值传递意味着完整拷贝。若结构体包含大量字段、嵌套结构或大数组（如 [1024]byte），每次调用都会触发内存复制，CPU 和 GC 压力上升。
- 典型信号：函数被高频调用，pprof 显示
runtime.memmove占比异常高 - 建议阈值：结构体大小超过 64 字节，优先考虑传指针（除非明确需要不可变语义）
- 验证方式：用
unsafe.Sizeof(T{})查看实际大小
字符串和切片的“假共享”错觉
字符串是只读值类型，底层含 ptr + len；切片是引用头（ptr + len + cap），也是值类型。二者传参都拷贝头部，但指向的底层数组不变 —— 这容易让人误以为“类似引用传递”。
注意 区别：
- 修改切片头（如
s = append(s, x)）不影响原切片，因为头被拷贝了 - 但通过
s[i] = x修改元素，会影响原底层数组（因为 ptr 相同） - 字符串永远不可改，所以不存在“改内容影响原值”的问题
这种混合行为常导致并发或重用场景出 bug，比如把一个切片传给多个 goroutine 并各自 append，结果彼此干扰。
方法集与接收者类型不匹配导致无法调用
定义了值接收者的方法，不能被指针变量调用？不对 —— Go 会自动解引用。但反过来，定义了指针接收者的方法，值变量无法调用（除非可寻址）。
更隐蔽的问题出现在接口实现上：
type S struct{} func (S) M() {} // 值接收者 var s S var i interface{M() } = s // ✅ OK var j interface{M() } = &s // ✅ OK（自动取值）func (*S) N() {} // 指针接收者 var k interface{N() } = s // ❌ 编译失败：s 不实现 N() var l interface{ N() } = &s // ✅ OK当函数参数是接口类型时，传值还是传指针，直接决定能否满足接口——尤其在泛型约束或 mock 测试中容易踩坑。
基本上就这些。值类型本身没问题，问题出在“想当然”地认为它像引用，或忽视拷贝边界。写函数前花两秒想想：这个参数我需不需要改它？它有多大？它会被谁实现接口？多数问题就能提前避开。
