是否加互斥锁取决于结构体是否被多个goroutine并发读写；只读无需锁，含可变字段（如map、slice、指针）且会被修改则必须加锁（mutex或rwmutex），sync.once不提供后续访问保护。
怎么判断一个结构体是否需要加互斥锁
Go 语言里没有“自动线程安全”这回事，struct 本身不带并发保护。是否加锁，只看它是不是会被多个 goroutine 同时读写——哪怕只是“一个写、多个读”，也得小心。
常见错误现象：fatal error: concurrent map writes 或数据莫名被覆盖、计数不准、字段值突变。这些往往不是 bug，而是没意识到某个 struct 字段正在被并发访问。
- 如果结构体只在初始化后只读（比如配置对象），不用锁
- 如果含
map、slice、指针或自定义字段，且任一 goroutine 会修改它，就必须加锁（sync.Mutex或sync.RWMutex） -
sync.Map不是万能替代品：它适合读多写少、键值生命周期长的场景；高频更新或需要遍历/长度统计时，性能反而不如带锁的普通map
用 sync.RWMutex 还是 sync.Mutex
区别不在“功能”，而在读写比例和等待行为。写操作永远会阻塞所有读和写，但读操作之间不互斥——这是 RWMutex 唯一的优势点。
使用场景：RWMutex 只在明确满足“读远多于写 + 读操作耗时不可忽略”时才值得引入。否则直接用 Mutex 更简单、更不容易出错。
- 读操作很快（比如只是取一个
int字段），用RWMutex反而增加调度开销 - 写操作频繁（比如每秒几十次以上），
RWMutex的写饥饿问题会暴露：读请求持续抢占，导致写一直等不到机会 - 别在持有
RWMutex.RLock()期间调用可能阻塞或调用其他锁的函数——容易死锁
为什么 sync.Once 不能用来保护普通变量赋值
sync.Once 是为“仅执行一次”的初始化逻辑设计的，比如加载配置、初始化单例、打开文件句柄。它不提供对变量后续读写的保护。
常见错误现象：用 sync.Once.Do() 初始化了一个 map，之后直接并发读写这个 map，结果触发 concurrent map writes panic。
-
sync.Once只保证那个函数体最多执行一次，不给里面创建的对象加锁 - 它内部用的是
Mutex，但锁的作用域仅限于 Do 函数执行期间 - 如果初始化的是可变对象（如
map、slice、结构体指针），后续访问仍需自己加锁或换用线程安全类型
goroutine 泄漏常被当成并发安全问题
很多“数据不一致”或“程序卡住”的反馈，实际是 goroutine 没退出，导致状态堆积、channel 阻塞、锁未释放。这不是并发安全本身的问题，但会让并发安全问题更难定位。
典型表现：pprof 查 /debug/pprof/goroutine?debug=2 显示成百上千个 goroutine 停在 chan send 或 sync.Mutex.Lock。
- 启动 goroutine 时，确保有明确的退出路径（比如通过
context.Context控制生命周期） - 向无缓冲 channel 发送数据前，确认一定有接收方；或改用带缓冲 channel + 超时机制
- 别在锁区内启动新 goroutine 并让它尝试获取同一把锁——极大概率死锁
并发安全设计最易被忽略的一点：它从来不是孤立的。锁的粒度、goroutine 生命周期、channel 使用方式、甚至 defer 的位置，都会相互影响。写完一段并发代码，先问自己一句：这个锁，到底保护了什么？有没有 goroutine 在等它，却永远等不到？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
