Go中修改结构体字段必须传指针，因函数参数是值传递，仅指针接收者（*T）能修改原数据；值接收者（T）只操作副本，且大结构体值传递性能差。
为什么修改结构体字段必须传指针
Go 语言中，函数参数是值传递。如果传入结构体变量本身，函数内对字段的赋值只作用于副本，原结构体完全不受影响。只有传 *T（指向结构体的指针），才能通过解引用 *p 触达原始内存地址。
常见错误现象：user.SetAge(25) 调用后 user.Age 仍是旧值——大概率因为 SetAge 方法接收者是 user User 而非 user *User。
- 方法接收者类型决定能否修改原始数据：
func (u *User) SetAge(a int)✅；func (u User) SetAge(a int)❌ - 调用时无需显式取地址：即使定义为指针接收者，
user.SetAge(25)仍可直接调用（Go 自动取址） - 但如果变量本身是
nil，指针接收者方法会 panic，需提前判空
指针接收者方法 vs 值接收者方法的性能差异
小结构体（如两个 int 字段）用值接收者开销小；但只要结构体包含切片、map、channel 或字段较多（>16 字节常见阈值），值传递会触发内存拷贝，指针接收者更高效且语义清晰。
典型场景：数据库模型、HTTP 请求上下文、配置结构体——这些几乎都该用指针接收者，否则修改无效 + 性能浪费。
立即学习“go语言免费学习笔记（深入）”；
- 切片字段本质是指针+长度+容量，但整个切片头仍是值，所以
append到字段切片时，值接收者无法更新原切片头 - 使用
go vet可检测“方法修改了值接收者字段但未生效”的可疑模式 - 统一性建议：只要结构体有任何一个方法需要修改字段，所有方法都应使用指针接收者，避免混淆
nil 指针调用方法时的 panic 风险
指针接收者方法允许在 nil 指针上调用——前提是方法内部不解引用该指针。一旦执行 u.name = "x" 或 len(u.items)（u.items 是切片字段），就会 panic: invalid memory address or nil pointer dereference。
这不是 bug，是 Go 的明确行为。容易被忽略的是：方法签名看起来安全，但内部调用了其他可能解引用的方法或字段访问。
- 防御写法：在方法开头加
if u == nil { return }或panic("User is nil") - 初始化检查比运行时 panic 更友好：比如构造函数返回
*User前确保非 nil，或用new(User)替代&User{}（两者等价，但前者意图更明确） - 注意：接口变量持有一个
nil指针时，其底层值为nil，但接口自身不为nil——这常导致误判
嵌套结构体中指针字段的修改陷阱
当结构体字段本身是指针（如 Profile *UserProfile），修改该字段指向的内容需双重解引用；若想替换整个指针，则只需一次赋值。这两者常被混用。
例如：u.Profile.Name = "Alice" 修改的是 u.Profile 所指对象的字段；而 u.Profile = &UserProfile{Name: "Bob"} 是让 u.Profile 指向新对象。后者若没做深拷贝，可能引发数据竞争。
- 字段指针为空时直接解引用会 panic，务必先检查：
if u.Profile != nil { u.Profile.Name = "X" } - 使用
u.setProfileName("X")封装逻辑，比裸写u.Profile.Name更可控 - JSON 解析（
json.Unmarshal）默认不会为 nil 字段分配内存，需预置非 nil 指针或用指针包装类型（如*string）
*u 多敲两个字符重要得多。 
