go test -race 必须实际运行并发代码才生效，未报竞态不等于无问题；需确保测试等待所有goroutine结束、避免值传递含锁结构体、正确使用锁覆盖全部访问路径，并在CI中控制并发数与超时。
go test -race 必须跑起来才算生效
没报竞态 ≠ 没问题，根本原因是 go test -race 只捕获运行时真实发生的读写交错，不是静态扫描。测试代码里启动了 goroutine，但没等它执行完就退出，或者只串行调用一次被测函数，-race 就完全没机会看到冲突。
- 确保测试函数以
_test.go结尾，且含func TestXXX(t *testing.T) - 用
sync.WaitGroup或chan struct{}等待所有 goroutine 结束，别用time.Sleep()—— 时间短了漏触发，长了拖慢测试 - 并发数别设 2 或 5，至少
const N = 1000，提高调度器交错概率 - 如果被测逻辑依赖 HTTP、定时器等，测试中必须 mock 或缩短超时，否则
-race可能因超时提前终止而跳过关键路径
struct 字段加了 mutex 还报 race？先查值传递
常见真 Bug 是：结构体含 sync.Mutex，但函数参数或 map value 用了值传递，导致每次传参都复制出一个新 mutex，原锁失效。race detector 会照常报警，因为实际没锁住共享字段。
- 所有含
sync.Mutex的 struct，函数参数、返回值、map value、channel 元素一律用指针*MyStruct - 检查是否在
defer mu.Unlock()前漏了mu.Lock()，尤其 if 分支里加锁、else 里没加的情况 - 确认
Lock()/Unlock()覆盖全部读写路径 —— 比如某个方法只读字段却没加RLock()，另一个方法写却用Lock()，也算未同步 - 避免对 struct 做深拷贝（如
json.Unmarshal到新实例），拷贝后锁和数据就分离了
map 并发读写别只盯着 panic，要靠 -race 定位真实写入点
fatal error: concurrent map writes 只告诉你炸了，但不知道哪两处代码在争。而 go test -race 会打出具体地址和两个 goroutine 的完整调用栈，这才是修复依据。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- panic 堆栈通常停在
runtime.mapassign，无意义；-race报告里的Write at 0x... by goroutine X和Previous write at 0x... by goroutine Y才是真实冲突行 - 别一上来就换
sync.Map—— 它适合读多写少、不遍历、键生命周期长的场景；写频繁或需len()/range统计时，sync.RWMutex包普通 map 更稳 - 如果用指针传 map（如
func update(m *map[string]int)），注意别在 goroutine 内执行*m = make(...)—— 底层地址变了，-race就无法关联历史访问
CI 里跑 -race 失败或超时？不是配置问题，是测试本身没控好 goroutine
CI 中 go test -race 偶发失败或超时，大概率不是工具问题，而是测试里 goroutine 泄漏或没设超时保护。
立即学习“go语言免费学习笔记（深入）”；
- 每个并发测试必须配
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，并在 goroutine 启动时传入 ctx，防止卡死 - 用
sync.WaitGroup时，wg.Add()必须在go前调用，且数量与启动 goroutine 数严格一致 - CI 环境资源受限，
-race本身变慢 2–5 倍、内存翻倍，所以测试并发数不宜盲目拉高，建议从 100 开始压测，再逐步调 - 第三方库内部的竞态也会被
-race报出，堆栈可能停在你调用它的那一行 —— 别直接改自己代码，先确认是不是复用了不该共享的全局实例（如http.DefaultServeMux）
-race 都可能在某次 CI 构建中突然炸出来。 
