必须用 MyStruct 而不是 MyStruct 的情况有五种：一是结构体含 sync.Mutex 等不可复制字段，否则编译报错；二是方法需修改接收者字段，值接收者仅作用于副本；三是结构体过大（如 [1024]byte），值传导致高频 memmove；四是只有 T 实现了某接口，传 T 值会类型不匹配；五是热路径中结构体超 64 字节且频繁传参，避免堆分配与 GC 压力。
什么时候必须用 *MyStruct 而不是 MyStruct？
不是“建议”，而是“不传指针就编译失败或运行崩溃”——这类结构体必须用指针：
-
sync.Mutex或其他不可复制字段（编译报错：cannot assign to struct containing sync.Mutex） - 方法需要修改字段，比如
func (u *User) SetName(n string)—— 值接收者改的是副本，毫无效果 - 结构体含大数组，如
[1024]byte：值传一次就拷贝 1KB，高频调用时runtime.memmove占比飙升 - 实现了某个接口，但只有
*T的方法集满足，你却传了T值：报错cannot use t (type T) as type Interface
实操建议：用 unsafe.Sizeof(MyStruct{}) 测真实大小。超过 64 字节，且在热路径（如 HTTP handler、goroutine 入口）中频繁传参，就该上指针。
传指针后为什么还会 panic: invalid memory address？
指针本身不危险，危险的是没检查 nil 就直接解引用。常见于以下场景：
- 函数参数是
*User，但调用方传了nil（比如数据库查不到返回nil，上层没处理） - 从
map[string]User中取值后直接取地址：&m["key"]编译不通过；正确做法是先赋给局部变量再取址 - 结构体字段本身是指针（如
Profile *UserProfile），链式访问u.Profile.AvatarURL前没判u.Profile != nil
实操建议：所有接收 *T 的函数，开头加 if t == nil { return errors.New("t is nil") }；构造函数统一用 NewT() 返回非 nil 指针，别裸写 &T{}。
立即学习“go语言免费学习笔记（深入）”；
func f(u User) 和 func f(u *User) 性能差多少？
差别不在“快或慢”，而在“是否可控”。小结构体（如 type Point {X, Y int}，24 字节内）值传更快：无解引用、CPU 缓存友好、逃逸分析更可能留在栈上；大结构体传值则触发大量堆分配，GC 压力肉眼可见。
- 实测对比：含 1000 个
int64的结构体（约 8KB），BenchmarkStructByValue分配次数和耗时是BenchmarkStructByPtr的 5–10 倍 - 看逃逸：加
go build -gcflags="-m"，若出现... moves to heap，说明值传强制升堆；而指针传参反而可能让原变量继续栈分配 - 别猜：用
go test -bench=. -benchmem看allocs/op和B/op，数据比直觉可靠
结构体内嵌指针字段，会影响外部传参策略吗？
不影响。结构体自身该传值还是传指针，只取决于它自身的大小和是否需修改，跟它内部字段是不是指针完全无关。
-
[]byte、map[string]interface{}、string本身已是“头部+指针”结构，赋值开销固定（24/16/8 字节），它们的存在会让结构体总大小变大，从而更倾向用指针传参 —— 但这仍是“总大小”驱动的，不是“因为里面有 slice 就得用指针” - 滥用
**T是典型反模式：多一层间接寻址，可读性差，还容易引发空指针 panic - 真正要优化的是字段顺序：把大字段（
int64、[64]byte）放前面，小字段（bool、int8）放后面，能减少填充字节 —— 这比盲目加指针更有效
最常被忽略的一点：指针不是性能银弹。它解决的是拷贝问题，但可能引入并发竞争、GC 压力或意外修改。先测瓶颈，再动指针，否则只是把问题从内存搬到了逻辑里。
