最常踩的坑是多个goroutine通过同一指针并发读写共享内存却未同步，导致concurrent map writes、nil pointer dereference或数据被莫名覆盖；本质是“共享内存+写=必须同步”，仅当指针指向全程只读且初始化后永不修改的数据时才可不加锁。
goroutine里传指针参数，最常踩的坑是啥
不是“能不能传”，而是“传了之后谁在改、改了谁在读、改完还用不用”。常见错误现象：fatal error: concurrent map writes、panic: invalid memory address or nil pointer dereference、数值莫名被覆盖但没报错。本质是多个 goroutine 通过同一指针访问共享内存，却没同步——哪怕只是读写结构体字段，只要没加锁或没隔离，就可能出问题。
什么情况下可以直接传指针进去不加锁
仅当该指针指向的数据**全程只读**，且其内容在所有 goroutine 启动前已完全初始化、后续绝不再修改。例如配置结构体、只读缓存、预计算的查找表。
- 结构体字段全是基础类型（
int、string、time.Time等），且构造后不再赋值 - 内部不含
map、slice、channel等可变容器；若含，这些字段本身也必须是只读的（比如用make([]int, n)初始化后从不append或重赋值） - 不传递
*map或*[]T这类“指针套引用类型”的组合——这等于把可变容器的控制权直接交出去
需要写操作时，怎么避免数据竞争
核心原则：**共享内存 + 写 = 必须同步**。不要依赖“我只改一个字段所以没事”这种直觉。
- 优先用
sync.Mutex或sync.RWMutex包裹对指针所指对象的读写——不是包裹 goroutine 启动逻辑，而是包裹实际访问字段的代码段 - 避免在 goroutine 内部缓存解引用结果，例如：
val := *ptr; doSomething(val)是安全的，但ptrField := &ptr.Field; use(ptrField)就危险，因为ptr.Field可能被其他 goroutine 同时修改 - 如果只是原子更新单个字段（如计数器），用
sync/atomic比锁更轻量：atomic.AddInt64(&obj.Counter, 1) - 别用
unsafe.Pointer替代同步机制——它不解决竞态，只绕过类型检查
返回指针给 goroutine 用，生命周期怎么兜住
最容易被忽略的一点：函数返回的指针，其指向的对象必须活过所有使用它的 goroutine。常见翻车场景是返回局部变量地址、或从切片中取地址后原切片被重新切或扩容。
- 返回
&localVar在函数退出后仍可用，是因为 Go 的逃逸分析会把它挪到堆上——但这不等于“你可以放心返回”，它只解决内存不回收问题，不解决并发安全 - 若指针来自切片（如
&slice[i]），确保该切片不会被append、copy或重新切片，否则底层数组可能被替换，地址失效 - 全局变量或长生命周期结构体中的字段地址相对安全，但需确认该结构体本身不会被整个替换（如
globalConfig = &newConfig） - 用
sync.Pool管理临时大对象指针时，记得归还前清空敏感字段，防止下一次取出时残留脏数据
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
