大型结构体值传递会触发完整内存拷贝；含大数组、slice/map字段或长字符串的结构体应传指针，但需检查nil并注意引用字段仍共享底层，小结构体（如point）值传递更高效。
大型结构体值传递会触发完整内存拷贝
Go 的参数传递永远是值传递，但“值”的大小取决于类型本身。对大型结构体（比如字段 ≥ 4 个、含 []byte / map / 大数组等），值传递不是只拷贝几个字段，而是整块内存复制——哪怕结构体里只有一字段是 [1024]byte，每次调用都得搬 1KB；若含 Avatar []byte（几 MB），拷贝开销肉眼可见。编译器不会帮你转成指针，这是开发者责任。
- 实测：512 字节结构体值传参比指针传参慢约 13 倍（35.2 ns vs 2.6 ns）
- 错误现象：
go build -gcflags="-m -l"显示moves to heap或大量allocs/op，说明栈拷贝已成瓶颈 - 典型踩坑：把
type Config struct{ Data map[string][]byte; Settings [2048]int }直接当参数传，函数一调用就卡顿
什么算“大型”？看字段组成，不看名字
别数“字段个数”就下结论。关键看是否含以下任一成分：
-
sync.Mutex等不可拷贝字段 → 值传递直接编译失败：cannot copy sync.Mutex - 大数组：
[1024]byte、[4096]int→ 拷贝成本固定且高昂 - slice/map/channel 字段 → 虽 header 只 24 字节，但函数内
append或delete可能意外影响原数据（你以为隔离了，其实没） - 字符串字段较多（尤其长字符串）→
stringheader 小，但底层数据可能驻堆，频繁传值加重 GC 压力
反例：type Point struct{ X, Y int }（16 字节）或 type UserLite struct{ ID int64; Name string }（≤ 24 字节）——值传递更高效，还避免解引用开销。
*T 参数必须检查 nil，否则 runtime panic
Go 不自动判空，*User 完全可能是 nil。HTTP handler 解析 JSON、DB 查询未命中、channel receive 都可能产出 nil 指针。一旦在函数里访问 u.Name 或 u.Avatar[0]，立刻崩溃：panic: invalid memory address or nil pointer dereference。
- 第一行就该写：
if u == nil { return errors.New("user is nil") } - 别写
if u != nil { ... }后面再处理逻辑——容易漏分支，也难维护 - 若业务允许可选（如部分更新），显式分支：
if u != nil { u.Avatar = newAvatar }，而非放任解引用
传指针 ≠ 数据安全，slice 和 map 字段仍共享底层
这是最常被忽略的陷阱：你传了 *User，以为改 u.Data 是局部操作，结果 u.Data[0] = 99 直接改到了原始 slice 底层数组。因为 []byte 字段只是 header（指针+长度+容量），值传递或指针传递都不影响其指向的底层数组。
- 想真正隔离？手动深拷贝：
newData := make([]byte, len(u.Data)); copy(newData, u.Data) - 更可持续：把字段设为私有，暴露
Data() []byte（返回副本）和SetData([]byte)（带校验） - 别迷信“传值就绝对安全”——Go 的值传递只复制结构体头，不递归复制引用字段内容
复杂点在于：是否真需要指针，得结合逃逸分析、并发场景和实际压测。比如小结构体配指针接收者，可能反而强制堆分配；而高并发下多个 goroutine 频繁读写同一缓存行里的不同字段，又可能引发 false sharing。先跑 go test -bench=.，再看 go tool pprof，最后动刀。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
