“write: broken pipe”不是panic，而是操作系统返回的epipe错误，由net.conn.write触发并透传为error，不进入recover捕获范围；它发生在http.server底层i/o层，不在handler goroutine执行栈中，因此中间件recover无效。
为什么 recover 捕不到 “write: broken pipe” 类 panic？
这类 panic 不是业务代码主动触发的，而是 Go 标准库在调用 conn.Write() 时底层系统调用失败（如客户端提前断开连接）后，由 http.Server 内部抛出的。它发生在 Gin 的 response writer 封装层之外，**不经过 HTTP handler 执行栈**，所以你在中间件 defer func() { recover() }() 里根本 catch 不到。
常见现象：panic: write tcp [::1]:8080->[::1]:56789: write: broken pipe 或 connection reset by peer，日志里有 panic，但自定义 Recovery 中间件没生效，服务可能卡顿或连接数异常上涨。
- 它不属于 handler goroutine 的 panic，而是由
http.Server的超时/关闭逻辑或底层 net.Conn 驱动的异步错误 - 即使你用了
gin.Default()，内置Recovery()也对它无效——因为 panic 没进中间件链 - 不能靠
c.Writer.Status()判断，此时响应早已开始写入，甚至部分 header 已发出去
http.Server 的 ErrorLog 是唯一可靠入口
Go 的 http.Server 提供了 ErrorLog 字段，专门用于捕获这类底层 I/O 错误。Gin 启动时用的正是这个 http.Server 实例，所以必须从这里切入。
实操建议：
- 初始化
http.Server时显式设置ErrorLog，不要依赖默认的log.Stderr - 把
io.Writer替换为自定义 logger（例如写入 zap、或过滤掉broken pipe后只告警非预期错误） - 注意：这个 log 输出的是字符串，不是
error类型，需用strings.Contains()做轻量判断，避免正则性能损耗
示例片段：
srv := &http.Server{
Addr: ":8080",
Handler: r, // your gin.Engine
ErrorLog: log.New(customWriter, "", 0),
}
如何区分该 panic 是否需告警？
“broken pipe” 和 “connection reset” 属于高频、可预期的网络抖动，**不应触发 P0 级报警**；但若同一秒内密集出现（比如 >10 次），或伴随其他错误（如 TLS handshake failed、timeout），就说明上游 LB 异常或客户端批量闪断，这时才值得介入。
- 在
customWriter的Write([]byte)方法里做计数 + 时间窗口滑动统计 - 只对非
broken pipe/connection reset的 panic（如invalid memory address、nil pointer）走完整告警通道 - 别在
ErrorLog里调用阻塞操作（如发邮件、HTTP 请求），否则会拖垮整个http.Server的错误处理吞吐
真正要防住的，是业务层主动写的 panic
你控制不了 TCP 层的断连，但你能控制自己是否在 handler 里调用 c.JSON() 后又 panic —— 这类组合会导致 http: multiple response.WriteHeader calls，而这个 panic 是能被 recover 捕获的。
- 所有响应写入操作（
c.JSON、c.String、c.Data）之后，禁止再触发任何可能 panic 的行为（如访问未初始化 map、解引用 nil 指针） - 尤其注意：
c.AbortWithError()后仍执行后续 handler 代码，如果后续有c.JSON()，就会冲突 - 用
go vet -shadow和静态检查工具提前发现变量遮蔽导致的 nil 访问
网络写中断本身不可防，但它的 panic 不该混进你的业务错误流里——分清楚哪层错误归哪层管，比堆砌 recover 更重要。
