必须用 go test -race 检测竞态，它是唯一能在内存访问层面实时捕获读写冲突的机制；需配合 sync.waitgroup 确保测试等待所有 goroutine 完成，禁用 time.sleep 和滥用 t.parallel()，并正确认知 sync.map、atomic 与 sync.once 的适用边界。
必须用 go test -race，其他方式基本无效
不加 -race 的并发测试，99% 是自欺欺人。本地跑十次全绿，CI 或线上某次 panic，大概率就是没开竞态检测。Go 运行时的 race detector 是唯一能在内存访问层面实时捕获读写冲突的机制，它不是模拟，是插桩实测。
常见错误现象：fatal error: concurrent map writes 在 CI 偶发、counter 值偶尔少几十、sync.Once 初始化被调两次——这些都不是“概率问题”，而是未同步访问的铁证，只是没被 -race 捕获而已。
-
go test -race -v ./pkgname是最小可行命令，别省掉-v，否则报错栈不显示 - 不能只测单个函数，比如
Counter.Inc()，要测它被多个 goroutine 调用的真实路径 -
-race会让测试变慢 2–5 倍、内存占用翻倍，所以仅用于测试环境，生产构建绝对不要加 - 如果
go run -race main.go立刻报WARNING: DATA RACE，说明问题就在那儿，不用再猜
并发测试里 sync.WaitGroup 不是可选，是必填项
测试函数启动 goroutine 后直接返回，等于没测。主 goroutine 提前退出，子 goroutine 被强制终止，结果永远“看起来正确”。sync.WaitGroup 是唯一可靠的方式，让测试真正等完所有并发操作。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
wg.Add(1)必须在go语句之前，且每个 goroutine 对应一次 -
defer wg.Done()必须写在 goroutine 函数体内，写在测试函数里会立刻减一 - 别用
time.Sleep替代等待——精度差、不稳定、拖慢测试，且无法保证 goroutine 真的执行完了 - 若需收集错误或结果，用带缓冲的
chan error（如make(chan error, 100)），避免阻塞
别碰 time.Sleep，也别信 t.Parallel() 能自动帮你并发
t.Parallel() 只表示“这个测试可以和其他标记了 Parallel 的测试一起跑”，它不控制你测试函数内部的 goroutine 行为，也不解决共享状态问题。滥用它反而更容易触发竞态——比如多个并行测试共用一个包级 map 或 sync.Pool。
- 每个并行测试必须用局部变量构造独立状态，禁止读写全局可变变量
- 如果要用共享资源（如 mock DB 连接池），必须用
sync.Once初始化，且该资源本身得线程安全 - 测试内起 goroutine，仍需
sync.WaitGroup或chan控制生命周期，t.Parallel()对此完全无感 -
go test -p 4可控并行数，但默认只用GOMAXPROCS个逻辑处理器，未必反映真实压力
sync.Map 和 atomic 不是万能解药，用错照样出事
把普通 map 换成 sync.Map 就以为万事大吉？或者对 int32 字段用 atomic.AddInt64？这类误用在测试中不会报错，但运行时一定崩。
-
sync.Map只保证其自身方法（Load/Store等）线程安全，如果你从Load出来一个非线程安全对象（比如*bytes.Buffer），再在多个 goroutine 里直接调它的Write，照样 race -
atomic操作必须严格匹配类型：atomic.AddInt64(&x, 1)要求x是int64，用int32会 panic 或静默失败 -
sync.Once.Do只保护传入的函数体执行一次，不保护该函数内部访问的其他共享变量——这是高频踩坑点 -
sync.Pool放进去的对象，取出后必须视为“全新实例”，不能假设它还保留上次的状态，尤其不能在不同 goroutine 中复用未重置的结构体
-race 就可能沉默，而线上会在某个凌晨三点突然爆掉。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
