必须用sync.waitgroup等同步机制确保所有goroutine完成后再读取atomic变量，否则会读到中间态；正确做法是多goroutine并发调用atomic操作并断言最终值，配合-go test -race检测竞态。
GoLand里跑带atomic的测试会卡住或不生效？
不是IDE的问题，而是atomic操作本身不触发任何可观测副作用，单纯执行atomic.AddInt64(&x, 1)不会自动暴露竞态或验证逻辑——你得主动构造并发场景并断言结果。GoLand只是运行go test，它不会“特殊处理”原子操作。
怎么写能真正验证atomic逻辑？
关键不是调用atomic函数，而是模拟多goroutine读写同一变量，并检查最终值是否符合预期。常见错误是只在单goroutine里反复调用atomic.LoadInt64，这等于白测。
- 必须用
sync.WaitGroup或sync/errgroup启动多个goroutine，对同一个*int64做atomic.AddInt64或atomic.CompareAndSwapInt64 - 所有goroutine结束后，用
atomic.LoadInt64读最终值，再和理论值比对（比如10个goroutine各加100，结果应为1000） - 如果想捕获数据竞争，要加
-race参数运行测试：go test -race -v，GoLand里可在Run Configuration → Go tool arguments填-race
为什么GoLand点击“Run Test”没报错但结果不对？
典型原因是没等所有goroutine结束就提前返回了。Go test函数退出后，后台goroutine可能还在跑，导致atomic.LoadInt64读到中间态。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 漏掉
wg.Wait()是最常见坑，defer wg.Done()写了但wg.Add(n)没配对也一样失效 - 别用
time.Sleep凑数——它不可靠，尤其CI环境调度更不确定 - 示例片段：
var counter int64<br>var wg sync.WaitGroup<br>for i := 0; i wg.Add(1)<br> go func() {<br> defer wg.Done()<br> atomic.AddInt64(&counter, 1)<br> }()<br>}<br>wg.Wait()<br>if got := atomic.LoadInt64(&counter); got != 10 {<br> t.Fatalf("expected 10, got %d", got)<br>}
性能敏感时要不要测atomic的内存序？
绝大多数业务代码不用显式指定atomic.LoadInt64的内存序（默认Relaxed），但如果你依赖顺序（比如用atomic.StoreInt64写标志位，再用atomic.LoadInt64读），就得确认是否需要atomic.LoadAcquire或atomic.StoreRelease。GoLand本身不提供内存序调试支持，得靠代码逻辑+注释+人工审查保证正确性。
真正容易被忽略的是：atomic操作只保证单个变量的原子性，不保证多个变量间的顺序——比如同时更新count和status两个int64，即使各自用atomic，也不能保证其他goroutine看到它们是“一起变”的。
