结构体指针赋值后字段没变，是因为误将指针变量重新赋值（如 p = &User{...}），未解引用修改原内存；正确做法是用 p.Name = "new" 或 (*p).Name = "new"。
结构体指针赋值后字段没变？检查是否漏了星号解引用
Go 里用指针修改结构体字段，最常见问题是：传了 *T，却在函数里直接给形参赋值，没碰 *p 指向的内存。结果原结构体毫发无损。
比如写 func update(p *User) { p = &User{Name: "new"} }，这只是改了局部指针变量 p 的指向，不影响调用方传进来的那个地址。
- 要改字段，必须显式解引用：
(*p).Name = "new"或更常用的p.Name = "new"（Go 允许省略括号） - 如果误写成
p = &User{...}，等于让p指向新内存，原结构体完全没被触碰 - 验证方式：在函数前后打印
&u（地址）和u.Name（值），确认地址不变、值变了才算成功
接收者用值类型还是指针类型？看是否需要修改字段
方法接收者声明为 func (u User) Modify() 还是 func (u *User) Modify()，直接决定能不能改原结构体。
值接收者会复制整个结构体，所有字段操作都在副本上；指针接收者才真正拿到原始内存地址。
立即学习“go语言免费学习笔记（深入）”；
- 只要方法里有字段赋值（
u.Name = "x"），就必须用指针接收者，否则编译不报错但逻辑无效 - 小结构体（如两个
int）用值接收者开销小；大结构体（含 slice/map/大数组）务必用指针，避免拷贝成本 - 混用风险：同一个类型既有值接收者方法又有指针接收者方法，会导致接口实现不一致——只有指针接收者能实现需要指针方法的接口
nil 指针解引用 panic：调用前必须判空
panic: runtime error: invalid memory address or nil pointer dereference 是运行时最常撞上的坑，尤其在结构体字段本身是指针时。
比如 type User struct { Profile *Profile }，若 u.Profile 是 nil，直接写 u.Profile.Age = 25 就崩。
- 解引用前必须检查：
if u.Profile != nil { u.Profile.Age = 25 } - 初始化别偷懒：构造结构体时，对内部指针字段显式赋值（
&Profile{}）或用工厂函数封装 - 数据库 ORM 场景下更危险：查不到记录时返回
nil，下游直接解引用就 panic，得统一加 guard
map/slice 字段修改不生效？它们本身是指针包装，但容器变量不是
结构体里字段是 map[string]int 或 []string，改元素值通常不用指针；但想替换整个 map/slice（比如 u.Data = make(map[string]int)），就必须用指针接收者。
因为 Go 中 map/slice 底层是包含指针的 header 结构，赋值操作只复制 header，所以改 u.Data["k"] = v 能影响原数据；但 u.Data = newMap 是重写 header，不改原结构体字段指向。
- 改元素值：
u.Data["key"] = 123—— 值接收者也 OK - 换整个容器：
u.Data = map[string]int{"a": 1}—— 必须指针接收者 - 追加 slice：
u.Items = append(u.Items, x)同样要指针接收者，因为append可能分配新底层数组
实际开发中，这类“一半生效一半不生效”的行为最容易让人困惑几小时。记住：改内容靠底层指针，换容器靠变量地址。两者不是一回事。
