golangci-lint 不检测数据竞争，仅支持静态分析；Go 官方 race 检测需用 go test -race 或 go run -race，其为动态插桩、概率触发，须结合多轮压测验证。
golangci-lint 本身不检测数据竞争
直接说结论：golangci-lint 不具备运行时数据竞争检测能力，它只做静态分析。Go 官方的数据竞争检测器是 go run -race 或 go test -race，底层依赖 librace 动态插桩。很多开发者误以为只要配置了 golangci-lint 就能发现 data race，结果线上出问题才意识到漏掉了关键环节。
哪些 linter 插件看似相关但实际不查 race
虽然 golangci-lint 集成了几十个 linter，但目前（v1.57+）没有任何一个能可靠识别并发读写未同步的变量。比如：
-
govet（通过govet -race？错 ——govet的-race标志早已被移除，现在仅剩-atomic检查原子操作误用） -
staticcheck可能报SA9003（未加锁的并发写），但仅限极简单模式：比如同一包内、无函数跳转、无 interface 动态分发的场景，漏报率极高 -
errcheck、gosimple等完全不涉及内存模型
正确接入 race 检测的实操方式
必须绕过 golangci-lint，单独使用 Go 原生命令。推荐在 CI 和本地验证中固定组合：
- 单元测试阶段加
-race：go test -race -short ./...（注意：不能和-cover同时用，会 panic） - 集成测试或主程序验证：
go run -race main.go（仅适用于可直接运行的入口，且需确保所有 goroutine 能在进程退出前完成，否则 race detector 可能来不及报告） - 构建后二进制检测：
go build -race && ./your-binary（适合模拟真实部署环境） - 注意环境变量：
GORACE="halt_on_error=1"可让首次 race 直接 panic，避免日志淹没
为什么本地跑 go test -race 却没报，线上却崩了
这是最常被忽略的点：race detector 是概率性触发，依赖调度时机和内存访问 pattern。常见原因包括：
- 测试用例没真正并发执行（比如忘了
go启动 goroutine，或用了sync.WaitGroup但没wg.Add()） - 竞态发生在初始化阶段（
init()函数），而go test默认不运行init外的包级逻辑 - 用了
time.Sleep模拟并发，但 race detector 对 sleep 不敏感；应改用sync.WaitGroup+ 显式 goroutine 启动 - CGO_ENABLED=0 时部分底层 sync 行为变化，影响 detector 行为（罕见但存在）
真正可靠的验证，得靠多轮随机压测 + -race，而不是单次 go test 成功就认为安全。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
