gin中死锁常因未调用c.copy()导致，因原始context绑定请求生命周期，goroutine中直接使用会触发panic或数据错乱；c.copy()深拷贝读取字段但不复制响应writer，仅适用于后台读取处理。
为什么 Gin 中的死锁常发生在 c.Copy() 忘记调用？
因为 gin.Context 是请求生命周期绑定的，底层持有 HTTP 连接、响应 writer、中间件栈等资源。一旦请求返回，Gin 会回收该上下文——但如果你在 goroutine 中直接使用原始 c（比如读 c.Param()、写 c.JSON() 或调用 c.ShouldBind()），而没调用 c.Copy()，就会在异步任务执行时触发 panic 或静默数据错乱。
常见错误现象：panic: reflect: call of reflect.Value.Interface on zero Value（来自 c.Get()）、http: response.WriteHeader on hijacked connection（尝试写响应）、或更隐蔽的 nil pointer dereference。
-
c.Copy()会深拷贝关键字段（如Params、Keys、Request的副本），但不复制 writer 和连接，所以它只适合「读取请求数据 + 后台处理」，不能用于写响应 - 若需在异步中记录日志或上报指标，必须用
c.Copy()；若只是取 URL 路径或 query，也可提前提取成局部变量，避免依赖上下文 - 别在
c.Copy()后继续调用c.Next()或c.Abort()—— 它们对副本无效，且可能干扰主流程
并发访问共享变量时，sync.Mutex 和 sync.RWMutex 怎么选？
选错锁类型不会直接死锁，但会导致性能瓶颈或误用风险。核心区别不在“能不能用”，而在“谁在读、谁在写、频率如何”。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 纯计数器、配置热更新、单次初始化（如
sync.Once）：用sync.Mutex最直白，Lock()/Unlock()成对 +defer基本能防住大部分问题 - 缓存 map、状态快照、高频读 + 低频写：必须上
sync.RWMutex，否则读多时所有 goroutine 互斥排队，QPS 断崖下跌 - 绝对不要在
RWMutex.RLock()持有期间调用Lock()—— 这是典型的嵌套锁死锁场景，Go 不允许升级锁 - 如果写操作本身也带条件判断（如“若 key 不存在才写”），优先考虑
sync.Map，它对读场景零锁，但注意其 LoadOrStore 不是原子 compare-and-swap，有竞态窗口
向 channel 发送数据却卡住，是不是 Gin 导致的？
不是。Gin 本身不创建或管理业务 channel，但开发者常在 handler 里启动 goroutine 往无缓冲 channel 发数据，又没配好接收方，结果整个请求协程卡死，看起来像 Gin “卡住了”。
- 无缓冲 channel：
ch := make(chan int)，发送即阻塞，必须确保有 goroutine 同时在select或等待，否则立刻死锁 - 带缓冲 channel：
ch := make(chan int, 1)，最多缓存 1 个值；第二次ch 仍会阻塞，除非有人消费 - 安全写法：用
select+default非阻塞发送，或加timeout防止无限等待：select { case ch - 切记：channel 的生命周期要和业务逻辑对齐。例如，一个请求对应一个 channel，应在 handler 返回前关闭（由发送方关），并确保所有接收 goroutine 已退出或通过
context.WithTimeout可取消
goroutine 泄漏导致的“假死锁”怎么快速定位？
程序没报 fatal error: all goroutines are asleep - deadlock!，但接口变慢、内存上涨、新请求不进来了——这往往是 goroutine 在 channel 上永久等待，没被回收。
- 用
runtime.NumGoroutine()打点监控，上线后每分钟打一次日志，突增就预警 - 本地调试时加
go tool trace，看 trace 文件里有没有大量 goroutine 停在chan send或chan recv状态 - 根本解法是让所有 goroutine 支持取消：用
context.WithCancel或context.WithTimeout传入，接收方在select里监听ctx.Done()，发送方检测ctx.Err() != nil就停发 - Gin 的
c.Request.Context()是天然可取消的，异步任务应继承它：go func(ctx context.Context) { ... }(c.Request.Context())，这样客户端断连或超时，goroutine 会自动退出
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
