-go test -race 是 go 官方唯一能实时捕获读写冲突的机制，必须显式启用并覆盖完整调用链路；它仅检测实际发生的竞态，无法发现未触发路径，且需配合正确锁粒度、原子操作返回值处理与 sync.pool/once 的状态重置。
直接用 go test -race 跑一遍，不通过就说明有竞态
别绕开这个工具——它是 Go 官方唯一能实时捕获读写冲突的机制。只要涉及多个 goroutine 访问同一变量（比如结构体字段、全局 map、缓存计数器），且没加锁或没用原子操作，-race 就能定位到具体哪两行代码在争抢内存地址。
常见错误现象：go run main.go 正常输出，但 go run -race main.go 立刻报 WARNING: DATA RACE；本地单测全绿，CI 或压测时偶发数据错乱或 panic。
- 必须显式启用：
go test -race -v ./pkg/...，不能只测单个函数，要覆盖真实调用链路（比如 HTTP handler → service → dao） - 不要在生产构建里加
-race：它会让程序慢 2–5 倍、吃更多内存，只用于开发和测试环境 - 如果
-race没报，不代表绝对安全——它只能检测“运行时实际发生的竞态”，对未触发的路径无能为力
sync.Mutex 加锁位置不对，比不加还危险
加锁不是保险丝，锁的范围和粒度错了，照样出问题。典型错误是只锁了写操作，漏掉读；或者把锁放在方法外层，但内部调用了非线程安全的第三方库。
使用场景：保护共享状态（如连接池计数、配置缓存、用户 session map）；避免 map 并发读写 panic。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 锁必须包裹所有访问共享变量的代码，包括读和写——
counter++是读+写，if counter > 0是读，都得包进去 - 避免锁嵌套：多个
sync.Mutex同时持有时，所有 goroutine 必须按相同顺序获取，否则极易死锁 - 别用
defer mu.Unlock()在锁内启动 goroutine：那个 goroutine 可能还在跑，而主协程已释放锁
用 sync/atomic 替代 Mutex 时，返回值被忽略
原子操作不是万能的，atomic.AddInt64 返回新值，但很多人只调用它，却不返回或赋值，导致逻辑错位——这是竞态检测器最常抓到的“伪安全”陷阱。
参数差异：atomic.LoadInt64(&x) 读取当前值，atomic.StoreInt64(&x, v) 写入，atomic.AddInt64(&x, 1) 增加并返回结果。漏掉返回值，等于白加。
- 正确写法：
return atomic.AddInt64(&seq, 1)，而不是只写atomic.AddInt64(&seq, 1)然后另起一行return seq -
atomic只适用于简单类型（int32/int64/uintptr/unsafe.Pointer），复杂结构体字段不能靠它保护 - 官方明确提醒：
Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package.
channel 和 sync.Once 的隐式并发风险常被低估
它们本身线程安全，但使用者很容易误以为“用了就万事大吉”。比如把非线程安全对象塞进 sync.Pool，再在不同 goroutine 中取出直接用；或以为 sync.Once.Do 能保护整个初始化块里的所有共享状态。
性能影响：sync.Pool 避免频繁分配，但若复用对象内部含未同步字段，反而放大竞态；sync.Once 开销极小，但只保证一次执行，不保护执行过程中产生的共享副作用。
-
sync.Pool.Get()返回的对象，必须重置其内部状态（如清空 slice、重置字段），不能假设它是干净的 -
sync.Once.Do(func(){ ... })里如果修改了外部全局变量，那些变量仍需额外同步措施 - channel 发送/接收本身安全，但若多个 goroutine 共享同一个 struct 指针并通过 channel 传递，该 struct 内部字段仍可能被并发读写
-race 漏掉、锁范围偏移、原子操作返回值丢弃、以及复用对象内部状态污染的情况。这些点不靠工具，得靠人盯代码逻辑。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
