结构体传值无法修改原数据，传指针可以；小结构体且只读宜传值，需修改或较大时宜传指针；接收者类型影响接口实现与方法集；字段用*string仅当需区分nil与""；优先值类型，除非实测拷贝成瓶颈。
结构体传值 vs 传指针：函数参数里改不改得动原数据
核心就一条：func (s Student) SetAge(a int) 改不动原始 Student，func (s *Student) SetAge(a int) 能改。因为前者拿到的是副本，后者拿到的是地址。
- 传值：适合只读小结构体（比如
type Point {X, Y int}），拷贝开销小，且天然防误改 - 传指针：必须用在需要修改字段、或结构体较大（比如含切片、map、几十个字段）的场景，否则性能损耗明显
- 常见错误：定义了
*Student接收者方法，却对不可寻址的临时值调用——比如Student{}.SetName("x")会编译失败，因为Student{}是字面量，没地址可取
方法接收者混用会导致接口实现失效
Go 的接口匹配规则很严格：如果一个接口方法是用 *User 接收者实现的，那只有 *User 类型才满足该接口，User 值类型不满足。
- 现象：
var u User; var i fmt.Stringer = u报错cannot use u (type User) as type fmt.Stringer，但i = &u就行 - 原因：值类型
User的方法集只包含值接收者方法；而*User的方法集包含值+指针两种接收者方法 - 建议：只要结构体有一个方法用了指针接收者，其余方法也统一用指针接收者，避免隐式不一致
结构体字段里该用 *string 还是 string？看语义，不是看大小
字段是否用指针，和“能不能改”无关，而和“要不要表达‘未设置’状态”有关。
-
*string：能区分nil（未提供）和""（明确设为空字符串），适合 API 请求体、配置结构体 -
string：零值""本身就有意义，比如type Config {Name string}，没传Name就该是空字符串，不用判nil - 坑点：用
*string就必须每次解引用前判空，if u.Name != nil { fmt.Println(*u.Name) }，漏判直接 panic
性能不是唯一标准，逃逸和 GC 压力常被低估
很多人以为“结构体大就一定传指针”，但实际中，频繁取地址再返回指针，可能让本该在栈上的小对象被迫逃逸到堆，反而加重 GC 压力。
- 验证方式：
go build -gcflags="-m -l" main.go，看变量是否 “moved to heap” - 典型陷阱：在函数内 new 一个结构体并返回其指针，哪怕它只有两个
int字段，也会逃逸 - 更稳妥的做法：优先用值类型，除非实测发现拷贝成为瓶颈（比如 pprof 显示
runtime.mallocgc占比异常高）
最常被忽略的其实是语义一致性：同一个结构体，有的方法改字段，有的只读，却混用值/指针接收者——这不是语法错误，但会让调用方无法预测行为，也埋下接口匹配隐患。
