Iris框架的app.Run()不能用于生产环境优雅关机，因其本质封装http.Server.ListenAndServe()并阻塞主goroutine，既不暴露*http.Server引用，也不支持传入context.Context，收到SIGTERM时进程立即终止，导致请求中断、事务未提交等问题。
iris 框架本身不提供开箱即用的优雅关机能力，必须手动接管底层 http.Server 实例并配合信号监听——否则调用 app.Run() 后进程收到 SIGTERM 会直接退出，正在处理的请求被 RST 中断。
为什么 iris.Run() 不能直接用于生产环境优雅关机
它本质是封装了 http.Server.ListenAndServe() 并阻塞主 goroutine，既不暴露 *http.Server 引用，也不支持传入 context.Context。一旦你写 app.Run(":8080")，就等于把控制权完全交出：
- 收到
SIGTERM（Kubernetes 默认发的信号）时，进程立即终止，无等待窗口 -
app.Shutdown()是 Iris v12+ 新增方法，但仅在你**显式构造并启动***http.Server后才有效，不是对Run()的补丁 - 常见报错现象：
connection reset by peer、SSE 连接突断、数据库事务未提交
如何从 iris 中“抠出” *http.Server 并接管 shutdown
必须放弃 app.Run()，改用标准库方式启动，并保留服务实例引用：
- 构造
http.Server时，Handler字段填app.Handler()（不是app本身） - 启动必须放在 goroutine 中，否则主 goroutine 阻塞，收不到信号
- 忽略
http.ErrServerClosed：这是Shutdown()正常完成的标志，不是错误 - 别提前调
ln.Close()—— Iris 不暴露 listener，要用srv.Serve(ln)方式自建 listener 才可控
srv := &http.Server{
Addr: ":8080",
Handler: app.Handler(),
}
go func() {
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatal(err)
}
}()
信号监听与 Shutdown() 调用的关键细节
Go 程序无法响应 SIGKILL（kill -9），所以优雅关机只依赖 SIGINT（Ctrl+C）和 SIGTERM（容器编排系统如 Kubernetes 发送）：
立即学习“go语言免费学习笔记（深入）”；
- 必须用
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)注册，不能只监听SIGHUP - 收到信号后，**立刻**调
srv.Shutdown(ctx)，中间不要加日志 flush、指标上报等逻辑——这会延长关闭窗口 -
ctx必须带超时：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)；不要 defer cancel()，否则还没开始 shutdown 就取消了 - 所有 handler 内部的阻塞操作（DB 查询、HTTP 调用、WebSocket 读写）必须使用带 ctx 的版本，否则会拖住 shutdown
WebSocket/SSE 等长连接为何仍会断开
http.Server.Shutdown() 只管理 HTTP 连接生命周期，对已升级的连接（如 Upgrade: websocket）完全无感知：
- WebSocket 升级后脱离
http.Server管理，底层 TCP 连接还在跑，但Shutdown()不会等它 - 必须手动维护活跃连接池（例如用
sync.Map存储*websocket.Conn），并在 shutdown 前遍历发送close帧（code1001） - 客户端必须实现重连逻辑，且新服务需能根据
session_id或last_seq恢复上下文 - 超时时间设太短（比如
5s）会导致流式响应被强制中断，建议长连接 draining 超时设为30–60s
实际部署中最容易被忽略的点：没设 ReadTimeout 和 WriteTimeout。它们不影响 Shutdown() 行为，但会导致慢客户端长期占用 worker，使 Shutdown() 超时后仍卡住，最终被 OS 强杀。
