Beego服务关闭时请求丢失因未注册信号监听导致强制中断；需手动启用优雅关闭：获取beego.BeeApp.Server实例，用signal.Notify监听SIGTERM/SIGINT，调用srv.Shutdown(ctx)并合理设置超时与上下文生命周期。
Beego 服务关闭时为什么会出现请求丢失？
Beego 默认使用 http.Server 启动，但未注册系统信号监听，进程收到 SIGTERM 或 SIGINT 时直接退出，正在处理的 HTTP 连接会被强制中断，导致客户端收到 connection reset 或超时。这不是 Beego 的 bug，而是未显式实现优雅关闭（graceful shutdown）的典型表现。
如何在 Beego 中启用优雅关闭？
Beego 1.12+ 内置了 bee.Run() 的优雅关闭支持，但需手动启用并配合信号捕获。关键不是替换启动方式，而是接管 http.Server 生命周期：
- 调用
beego.BeeApp.Server获取底层*http.Server实例 - 用
signal.Notify监听os.Interrupt和syscall.SIGTERM - 收到信号后，调用
srv.Shutdown(ctx)，而非srv.Close() - 确保所有异步任务（如定时器、goroutine）也响应上下文取消
示例片段：
srv := beego.BeeApp.Server
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
<!-- 注意：此处不能用 srv.ListenAndServe()，它会阻塞 -->
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
beego.Error("server exited:", err)
}
}()
<!-- 等待信号 -->
<!-- 创建带超时的 context -->
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
<!-- 阻塞等待 Shutdown 完成 -->
<!-- 注意：Shutdown 不会关闭 listener，需自行处理 -->
<!-- Beego 不自动调用 Shutdown，必须手动触发 -->
<!-- 收到信号后执行 -->
<!-- <code>srv.Shutdown(ctx)</code> -->
Beego 2.x 中 app.Run() 与优雅关闭的兼容性
Beego 2.x 将启动逻辑封装进 app.Run()，但该方法内部仍调用 http.Server.ListenAndServe()，且不暴露 srv 实例。此时必须绕过 app.Run()，改用底层 http.Server 启动：
- 禁用 Beego 自动启动：设置
beego.BConfig.Listen.DisableHTTP = true - 手动构建
http.Server，将beego.Handler作为Handler - 使用
srv.Serve(lis)启动，而非srv.ListenAndServe()，以便复用已创建的 listener - 注意
beego.Handler是http.Handler接口实现，可直接复用
否则直接调用 app.Run() 后无法获取控制权，优雅关闭将失效。
常见陷阱：超时时间设太短或没设、context 被提前取消
很多实现把 context.WithTimeout 设为 5 秒，但实际业务可能有长轮询、文件上传或数据库事务未完成，导致 Shutdown 强制终止连接。更糟的是，在 Shutdown 前就调用了 cancel()，使上下文立即失效，Shutdown 变成秒退。
- 超时应根据最长可能请求路径设定，例如上传接口最大耗时 60 秒 → 至少设 75 秒
-
cancel()必须在Shutdown返回后调用，不能放在 defer 中 - Beego 中间件若启用了 goroutine（如日志异步刷盘），需额外监听
ctx.Done()并清理 - 数据库连接池（如
sql.DB）需单独调用db.Close()，Shutdown不会自动处理它
优雅关闭不是加几行 signal 代码就完事，它是一整套生命周期协同——HTTP 服务器、中间件、数据连接、后台任务，都得对同一个上下文做出响应。
