Buffalo 应用关闭时需手动接管信号并调用 http.Server.Shutdown() 以安全等待活跃请求完成，同时在 Shutdown 完成后调用 app.Stop() 释放数据库、WebSocket 等资源，并确保业务 handler 内部子 context 超时与 Shutdown 超时嵌套一致。
Buffalo 应用关闭时如何避免请求被强制中断
Buffalo 默认使用 http.Server 启动，而 Go 标准库的 http.Server.Shutdown() 是唯一能安全等待活跃请求完成的机制——但 Buffalo 没有自动调用它，直接 os.Exit() 或进程信号终止会导致正在写响应的 goroutine 被杀掉，出现连接重置、JSON 截断、数据库事务残留等问题。
必须手动接管信号并调用 Shutdown()
Buffalo 的 app.Serve() 是阻塞式启动，不暴露底层 *http.Server 实例，所以不能直接调用 Shutdown()。你需要绕过 app.Serve()，改用 app.HTTP.Handler 构建自定义 server：
- 用
buffalo.New(buffalo.Options{...})创建 app 实例，但不要调用app.Serve() - 手动初始化
http.Server，把app.HTTP.Handler作为Handler字段传入 - 监听
os.Interrupt和syscall.SIGTERM，收到后调用server.Shutdown()并传入超时 context - 务必设置合理的超时（如 10 秒），防止长轮询或大文件上传无限阻塞退出
Shutdown() 期间新请求会被拒绝
调用 Shutdown() 后，server 会关闭 listener，不再接受新连接，但已建立的连接和正在执行的 handler 会继续运行直到完成或超时。这意味着：
- 你不需要额外加锁或标记“维护中”——底层已处理
- 如果 handler 内部有耗时操作（如未设 timeout 的 DB 查询、外部 HTTP 调用），它仍会拖慢 shutdown 进程，必须在业务逻辑里控制子 context 超时
- 日志中会出现
http: Server closed，这是正常信号，不是错误
别忽略 app.Stop() 的清理职责
Shutdown() 只管 HTTP 层，Buffalo 自身的资源（如数据库连接池、WebSocket hub、定时任务）需显式释放。Buffalo 提供了 app.Stop() 方法，但它不会自动触发，必须在 Shutdown() 完成回调里手动调用：
- 在
server.Shutdown()的err返回后立即执行app.Stop() - 确保
app.Stop()不会阻塞——比如它内部调用的db.Close()本身也有超时，需提前配置 - 若用了
buffalo.Worker或自定义后台 goroutine，得自己用sync.WaitGroup或context.WithCancel管理生命周期
真正容易被忽略的是：shutdown 超时时间与业务 handler 内部子 context 超时必须嵌套一致，否则外层关了，内层还在发数据库请求，连接池可能泄漏。这问题在线上压测时才明显，开发阶段很难复现。
