Go并发测试需启用go test -race捕获数据竞争，用sync/atomic处理简单类型原子操作，避免竞态；慎用sync.Map，优先考虑sync.RWMutex包裹普通map；并发测试须用sync.WaitGroup和超时机制防goroutine泄漏。
用 sync/atomic 和 race detector 捕获数据竞争
Go 自带的竞态检测器是并发测试的第一道防线，它能在运行时发现绝大多数未加保护的共享变量访问。启用方式很简单：在 go test 时加上 -race 标志。
常见错误现象是：本地测试不报错，CI 或高负载下偶尔 panic 或返回错误结果——这往往就是竞态未被发现的表现。
- 必须在所有并发测试中启用
go test -race，不能只在开发机跑一次就认为安全 -
sync/atomic适合简单类型（如int32、uint64、指针）的读写，但不能替代互斥锁处理复合逻辑（比如“读-改-写”） - 注意
atomic.LoadUint64(&x)和atomic.StoreUint64(&x, v)的参数必须是指针，传值会编译失败
用 testing.T.Parallel() 控制测试并发粒度
多个测试函数并行执行时，若共用全局状态（如包级变量、临时文件路径、数据库连接池），极易引发干扰。此时需明确划分作用域或隔离资源。
使用 testing.T.Parallel() 并不等于“自动线程安全”，它只是告诉测试框架可以和其他标记了 Parallel() 的测试一起调度；真正安全与否取决于你是否管理好了共享资源。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个测试函数内创建独立的
sync.Mutex或sync.Map实例，避免复用包级锁 - 不要在
init()或包变量初始化中启动 goroutine，它们会在所有测试间共享 - 对依赖外部服务的测试，优先用内存模拟（如
bytes.Buffer替代文件，httptest.Server替代真实 HTTP 调用）
用 sync.WaitGroup + time.After 防止 goroutine 泄漏
并发测试中最隐蔽的问题之一是 goroutine 泄漏：启动了 goroutine 却没等它结束，导致测试提前返回，后续执行不可控。
典型错误是只用 go fn() 启动，却忘了同步机制；或者用了 select 等待 channel，但没设超时，测试卡死。
- 务必用
sync.WaitGroup计数，且wg.Add()必须在 goroutine 启动前调用 - channel 接收逻辑一定要配
time.After或context.WithTimeout，否则测试可能永远阻塞 - 可在测试末尾加
runtime.GOMAXPROCS(1)和runtime.GC()辅助观察泄漏，但不能替代正确同步
用 sync.Map 替代 map 测试并发读写场景
普通 map 在并发读写时会直接 panic：“fatal error: concurrent map read and map write”。这不是 bug，而是 Go 的主动保护机制。
sync.Map 是为高频读、低频写的并发场景优化的，但它不是万能替代品：零值不可直接断言类型，不支持遍历一致性保证，且比原生 map 开销大。
- 仅当确实需要多 goroutine 同时读写同一张表时才用
sync.Map；否则优先用sync.RWMutex包裹普通map - 测试中验证
sync.Map行为时，别只测单次Load/Store，要构造多个 goroutine 同时Range+Store的混合操作 - 注意
sync.Map.LoadOrStore(key, value)返回的是实际存入的值和是否为新存入的布尔值，常被误判为“是否命中缓存”
并发测试真正的难点不在语法，而在于能否把“谁在什么时候访问什么资源”理清楚。哪怕加了锁，如果锁的粒度不对、顺序不一致，照样死锁或竞争。多打日志、少凭直觉，才是稳住并发测试的关键。
