Buffalo dev 不支持优雅停机，因其内部使用阻塞式 http.ListenAndServe() 且不暴露 *http.Server 实例，也未注册信号监听；必须手动构造 http.Server 并注入 app.Handler，配合 signal.Notify、context.WithTimeout 和 srv.Shutdown() 实现优雅关闭，并按序关闭数据库等资源。
buffalo dev 不支持优雅停机，必须绕过它启动
直接运行 buffalo dev 无法实现优雅停机——它内部用的是阻塞式 http.ListenAndServe()，不暴露 http.Server 实例，也未注册信号监听。你发 SIGTERM，进程直接 kill，数据库连接、HTTP 长连接、goroutine 都没机会清理。
真正能控制停机逻辑的，只有手动构造 http.Server 并注入 app.Handler：
- 删掉
app.Serve()或app.Start()调用 - 在
main.go中显式创建http.Server，把app.Handler设为Handler - 用带缓冲的
chan os.Signal监听os.Interrupt和syscall.SIGTERM - 收到信号后调用
server.Shutdown()，传入带超时的context.WithTimeout()
db.Close() 必须和 server.Shutdown() 协同执行
Buffalo 的 pop.Connection 是独立资源，server.Shutdown() 不会自动关数据库。常见错误是只关 HTTP server，留下空闲连接池持续占着 DB 连接，导致下次启动时报 too many connections。
正确顺序是：
立即学习“go语言免费学习笔记（深入）”；
- 先停止接收新请求（
server.Shutdown()） - 等所有活跃 handler 返回（靠 context 超时或主动检查
c.Request().Context().Done()） - 再调用
db.Close()，确保连接池彻底释放 - 最后
os.Exit(0)
别用 defer db.Close() —— 它在 main 函数退出时才执行，而 server.Shutdown() 可能已卡住，defer 永远等不到。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
中间件不传递 context 就会卡住 Shutdown()
server.Shutdown() 超时失效的最常见原因，是某个中间件或 handler 忽略了 context.Context，比如：
- 用
time.Sleep(5 * time.Second)硬等，而不是select { case - 数据库查询没传
ctx给pop.Query，底层sql.DB.QueryContext()没生效 - 日志中间件里调用了阻塞 I/O（如同步写文件），且没响应
ctx.Done()
Buffalo 的 buffalo.Context 包装了 request context，但你得在自定义中间件中显式提取并传递：
func MyMiddleware(next buffalo.Handler) buffalo.Handler {
return func(c buffalo.Context) error {
ctx := c.Request().Context()
// 所有下游调用都要用这个 ctx
return next(c)
}
}超时时间设太短或太长都不可靠
Shutdown 超时不是越长越好。设成 30 秒，可能掩盖 handler 本身 bug；设成 2 秒，又容易误杀还在处理的请求。
建议按实际负载定：
- 纯 API 服务：5–10 秒足够（多数 handler 在 100ms 内返回）
- 含文件上传或报表导出：需延长至 30–60 秒，并配合前端取消机制
- 务必设置
ReadTimeout和WriteTimeout到http.Server，否则未发完 body 的 POST 请求会让Shutdown()无限等待
最容易被忽略的是：Buffalo 默认没设任何 timeout，http.Server 的 ReadHeaderTimeout、IdleTimeout 全是 0，得手动补全。
