beego.bconfig.listen.graceful = true 启用基于 sighup 的 fork 热重启，老进程处理完存量请求后退出；它不响应 sigterm/sigint，且在容器等环境中因 fork 限制易失效，需手动补充 sigterm 优雅关闭逻辑。
beego.BConfig.Listen.Graceful = true 是什么作用
它开启 beego 内置的优雅退出支持，但**不是监听 SIGINT/SIGTERM 做 shutdown，而是监听 SIGHUP 实现优雅重启**。设为 true 后，beego 会 fork 新进程启动服务，老进程继续处理存量请求，直到全部完成才退出。这是 beego 特有的“热重启”语义，和标准 HTTP 服务的 graceful shutdown（仅关闭监听、等待请求结束）不是一回事。
常见误解是以为开了这个就自动响应 kill -15 或 Ctrl+C —— 实际上不会。它只对 SIGHUP 生效，且必须配合 beego.Run() 启动方式（非手动调用 http.Server）。
- 配置方式有两种：
beego.BConfig.Listen.Graceful = true或在conf/app.conf中写Graceful = true - 触发命令必须是
kill -HUP <pid></pid>，kill -TERM或kill -INT仍会导致立即退出（除非你额外加信号监听逻辑） - beego 2.x 及以上版本默认禁用该功能，因为 fork 模式在容器环境有兼容性问题（如 PID 1 限制、/proc 文件系统挂载差异）
为什么设置了 Graceful = true 却不响应 kill -HUP
最常见原因是进程没有以 beego 标准方式启动，或者被封装在 wrapper 脚本中导致信号未透传。beego 的 SIGHUP 处理逻辑在 beego.Run() 内部初始化，若你绕过它（比如自己 new http.Server + beego.Handler），SIGHUP 就完全不会被捕获。
另一个隐蔽问题是：某些 init 系统（如 systemd）或容器运行时（如 docker run）默认屏蔽或重定义了 SIGHUP。例如 docker 默认将 SIGHUP 转发给 PID 1 进程，而如果 beego 不是 PID 1，信号就丢了。
- 验证是否生效：启动后执行
ps -o pid,ppid,sig,comm -p $(pgrep -f 'beego')，确认进程确实收到并处理了SIGHUP - 容器中使用
docker kill --signal=HUP <container></container>，而非docker exec <container> kill -HUP 1</container>（后者可能因权限或命名空间隔离失败） - systemd 服务需显式设置
KillSignal=HUP，否则仍走默认SIGTERM
如何让 beego 同时支持 SIGHUP（重启）和 SIGTERM（退出）
beego 自身不提供对 SIGTERM 的优雅 shutdown 支持，必须手动补全。核心思路是：保留 beego 的 Graceful = true 用于 SIGHUP，再用 os/signal 单独监听 SIGTERM，调用 beego.BeeApp.Shutdown()（beego 2.0+）或模拟 server.Close() 流程。
关键点在于 shutdown 时机：不能直接调 beego.BeeApp.Shutdown()，因为 beego 的路由和中间件可能还在处理请求；必须等所有活跃请求自然结束，这需要依赖底层 http.Server 的 Shutdown() 方法。
- 先通过
beego.BeeApp.Server获取底层*http.Server实例（注意：beego 1.x 中该字段为私有，需反射或升级） - 监听
syscall.SIGTERM和os.Interrupt，收到后调用srv.Shutdown()并传入带超时的context.Context -
srv.Shutdown()返回后，再调beego.BeeApp.Shutdown()清理框架层资源（如定时任务、日志 flush） - 务必在
signal.Notify()前加signal.Ignore(os.Interrupt, syscall.SIGTERM)，否则进程会收到信号立刻退出，根本走不到你的清理逻辑
beego 优雅退出容易被忽略的兼容性坑
beego 的优雅机制高度依赖进程模型和信号传递路径，在现代部署环境中极易失效。最常被忽略的是：它假设进程能自由 fork 子进程，但在容器、serverless 或 systemd user session 下，fork 权限常被限制或重定向。
另一个隐形陷阱是日志同步 —— beego 默认日志写入是 buffered 的，Shutdown() 阶段若没显式 logs.Flush()，最后几条日志会丢失，导致你以为请求已处理完，实际 panic 日志根本没刷出。
- 容器中禁用
Graceful = true，改用标准SIGTERM → Shutdown()流程，避免 fork 失败导致整个进程 hang 住 - beego 1.x 用户无法直接访问
http.Server，只能降级为粗暴os.Exit(0)，或自行 patchbeego.Run()注入 shutdown 逻辑 - 所有后台 goroutine（如定时器、消息消费者）必须统一接收同一个
context.Context，不能靠time.AfterFunc或裸go func()，否则 shutdown 时它们还在跑
