go中goroutine修改结构体字段无效，是因为传参为值拷贝，操作的是副本而非原始结构体；必须传结构体指针（如 &u）才能修改原字段，但指针不解决并发竞争，多goroutine读写仍需锁或atomic。
goroutine 中直接修改结构体字段为什么无效
因为 Go 的 goroutine 启动时传参是值拷贝，如果传的是结构体值（如 go f(myStruct)），函数内部拿到的是副本，任何字段修改都只作用于栈上临时内存，原结构体完全不受影响。常见现象是：goroutine 里 u.Name = "new" 看似执行了，但主 goroutine 查 u.Name 还是旧值。
必须用指针传参才能真正修改原始结构体
只有让 goroutine 操作原始内存地址，修改才可见。关键不是“加锁”，而是“传地址”：
-
go updateName(&u)—— 传结构体指针，updateName内部用u.Name = "new"即可生效 - 若结构体存于切片中，确保传的是
&s[i]而非s[i] - 若结构体存于 map 中，必须存指针类型（如
map[string]*User），再传map[key]（它本身就是指针）
并发读写同一字段时才需要同步机制
指针解决了“能否改”的问题，但不解决“多 goroutine 同时改”的竞争问题。只有当多个 goroutine 可能同时读写同一个字段时，才需额外保护：
- 简单场景：用
sync.Mutex或sync.RWMutex包裹字段访问 - 计数类字段：优先用
sync/atomic（如atomic.AddInt64(&u.Counter, 1)） - 避免在 goroutine 中对结构体字段做复合操作（如
if u.Flag { u.Count++ }），这需要原子性或锁 - 不要用
unsafe.Pointer绕过同步——它不提供线程安全保证
接口切片里存结构体值会导致 goroutine 修改失效
这是最隐蔽的坑：把结构体值（而非指针）存进 []interface{}，再从里面取出来传给 goroutine，即使你用了 &v.(MyStruct)，得到的也是接口内存储的副本地址，不是原始结构体地址。
- 错误写法：
slice = append(slice, MyStruct{Name: "old"})→go f(slice[0].(MyStruct)) - 正确写法：
slice = append(slice, &MyStruct{Name: "old"})→go f(slice[0].(*MyStruct)) - 验证是否生效：打印结构体地址（
fmt.Printf("%p", u)），确保 goroutine 内外地址一致
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
