gin.context 不能跨 goroutine 直接使用，需调用 c.copy() 复制快照或提前提取字段；多 goroutine 写日志必须通过 channel 串行化，避免 write 系统调用交错导致乱序。
并发读写共享资源时，gin.Context 不能直接跨 goroutine 使用
常见错误是把 c（原始 *gin.Context）直接传进 goroutine 做异步处理，比如日志记录或消息推送。请求一结束，Gin 就回收并清空上下文内存，后续访问 c.Request.URL、c.GetHeader() 或 c.MustGet() 都可能 panic 或返回 nil。
正确做法是调用 c.Copy() 显式复制一份上下文副本：
-
c.Copy()复制的是当前请求状态快照，包含 query、header、body 数据和已存入的键值对（c.Set()的内容），但不包含响应写入能力（c.JSON()等会失效） - 若只需提取少量字段（如用户 ID、trace ID），更轻量的做法是提前取出：
userID := c.GetString("user_id")，再传入 goroutine - 避免在 goroutine 中调用
c.Abort()、c.Next()或任何影响响应流程的方法
多个 goroutine 同时写同一文件（如日志）必须收束到单个 writer
哪怕开了 os.O_APPEND，多个 goroutine 直接调用 file.WriteString() 仍会因底层多次 write() 系统调用交错，导致日志行断裂、乱序、字符粘连——这不是小概率事件，是确定性行为。
可靠方案是用 channel 把写请求排队交给一个专属 goroutine：
- 定义结构体：
type LogMsg struct { ts time.Time; level string; msg string } - 启动 writer goroutine：
go func() { for msg := range logCh { fmt.Fprintln(file, msg.String()) } }() - 生产者侧直接
logCh ，channel 容量建议设为 1024 或使用无缓冲通道（<code>make(chan LogMsg)）以自然背压 - 务必在服务 shutdown 前 close(
logCh)，接收端用for range安全退出
并发修改结构体字段必须加锁，sync.RWMutex 不是万能的
读多写少场景下，sync.RWMutex 能提升性能，但它只解决“读并发、写互斥”问题。如果结构体字段之间存在强依赖（比如 status 和 lastUpdate 必须原子更新），仅靠 RLock/RLock 无法保证逻辑一致性。
例如缓存结构体中同时更新 data 和 ttl：
- 错误：分别对两个字段加
RWMutex锁，或只读锁保护data、写锁保护ttl—— 可能读到过期data+ 新ttl，或新data+ 过期ttl - 正确：所有相关字段统一由同一个
sync.Mutex或sync.RWMutex保护，且写操作必须成块完成 - 更严格场景（如配置热更新），推荐用 channel 封装变更请求，由单一 goroutine 序列化执行，避免锁竞争和死锁风险
不要用 sync.Mutex 包裹 *os.File.Write 来“修复”并发写
给 file.Write() 加锁看似简单，实则掩盖了更深层问题：锁住 Go 层调用，并不能约束内核 write 缓冲区行为；高负载下锁粒度与 I/O 延迟严重失配，容易造成 goroutine 大量阻塞，吞吐骤降。
真正的问题不在“要不要锁”，而在于“谁该负责写”：
- 锁
file.Write()是把业务逻辑强行串行化，违背 Go “通过通信共享内存” 的设计哲学 - 一旦写入失败（如磁盘满、权限丢失），错误只能在 writer goroutine 内部处理，上游无法感知，易埋隐患
- 若需写入失败重试或降级（如切到备用文件），必须把错误传播机制设计进 channel 协议，而非依赖锁外的 panic 捕获
复杂点从来不在锁怎么加，而在写入责任是否清晰、错误路径是否可观察、背压是否可控——这些恰恰是 channel 方案天然支持的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
