gin handler触发数据竞争是因为每个请求在独立goroutine中执行，若共享全局变量（如map、int）未加锁保护就会竞态；应使用sync.rwmutex或atomic等同步机制避免。
Gin 本身不引入额外 goroutine 锁，但你写的 handler 里如果共享变量没保护，就会出竞态 —— 这不是 Gin 的锅，是 Go 并发模型的必然要求。
为什么 Gin handler 会触发数据竞争？
每个 HTTP 请求由独立 goroutine 执行，gin.Context 是非共享的，但全局变量（如 map、int、slice）不是。常见错误包括：
- 在 handler 中直接修改未加锁的全局
visits计数器 - 多个请求并发写同一个
logFile *os.File而没用sync.Mutex - 用
time.AfterFunc异步更新结构体字段，却没考虑该结构体被其他 goroutine 同时读取
Go 的 go run -race 会立刻报出这类问题，比如：Read at 0x00c0001243a0 by goroutine 8 + Previous write at 0x00c0001243a0 by goroutine 7。
用 sync.RWMutex 保护读多写少的共享状态
计数器、配置缓存、白名单列表等场景，读远多于写，sync.RWMutex 比普通 sync.Mutex 更高效：
var (
visits = make(map[string]int
visitMu sync.RWMutex
)
func handler(c *gin.Context) {
ip := c.ClientIP()
visitMu.RLock()
count := visits[ip]
visitMu.RUnlock()
// 只在需要更新时才写锁
if count%100 == 0 {
visitMu.Lock()
visits[ip]++
visitMu.Unlock()
}
}
注意：不要在 RUnlock() 前 return，否则锁永远不释放；也不要嵌套 RLock + Lock，可能死锁。
别在 handler 里直接起 goroutine 改全局变量
以下写法极危险：
r.POST("/inc", func(c *gin.Context) {
go func() {
counter++ // ❌ 竞态！无锁、无同步
}()
c.Status(200)
})
正确做法是：
- 用
sync.Mutex或atomic.Int64（仅限整型）保护写操作 - 若逻辑复杂，把状态变更封装进带锁的方法，handler 只调用它
- 避免在 goroutine 中访问
c.Request或c.Writer—— 它们生命周期只到 handler 返回
尤其注意：Gin 的 c.Copy() 只复制 context 数据，不复制底层 http.ResponseWriter，异步中调用 c.JSON() 必 panic。
容易被忽略的隐式共享：sync.Pool 和中间件
Gin 的 Engine.pool 复用 *gin.Context，但复用不等于共享 —— 每次请求拿到的是“干净”的实例。真正危险的是你自己往 c.Set() 存东西后，在中间件或 handler 里跨请求误用。
例如：
func authMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
user, _ := getUser(c)
c.Set("user", user) // ✅ 正常
c.Next()
}
}
func logMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
// ❌ 危险：如果中间件顺序错，这里取到的可能是上个请求留下的 "user"
u := c.MustGet("user")
log.Printf("user: %+v", u)
}
}
这种 bug 不会触发 race detector，但会导致脏数据。解决方案：确保中间件执行顺序严格，或改用 context.WithValue() 显式传递。
