直接 kill -9 会导致请求丢失，因其发送 sigkill 信号使 go 进程无法捕获，goroutine 瞬间终止，http 连接、数据库事务、文件上传等均未完成；应改用 sigterm/sigint/sigquit 配合 http.server.shutdown() 实现优雅关闭。
为什么直接 kill -9 会让请求丢得莫名其妙
因为 SIGKILL 是内核级强制终止信号，Go 进程连捕获的机会都没有，所有正在运行的 goroutine 瞬间被掐断——HTTP 连接还没读完 body、数据库事务刚写一半、文件上传卡在中间，全算“未完成”。用户看到的是 502 或超时，后台可能是“钱扣了但订单没生成”。
-
kill -9不可监听、不可拦截，加signal.Notify也完全无效 - 真正能响应的只有
SIGINT（Ctrl+C）、SIGTERM（k8sdelete pod）、SIGQUIT（某些 systemd 场景） - 别漏掉
SIGQUIT：它不是“调试用”，而是部分容器平台和 init 系统的真实行为
怎么用 http.Server.Shutdown() 替代 router.Run()
router.Run(":8080") 是阻塞调用，没法插手关机逻辑；必须退回到标准库 http.Server，才能调用 Shutdown()。
- 先构造
&http.Server{Addr: ":8080", Handler: router}，别直接用router.Run() - 启动服务要放在
go func()里，否则主线程被占住，信号根本收不到 -
Shutdown()必须传入带超时的context.Context，比如context.WithTimeout(context.Background(), 5*time.Second) - 别用
context.Background()直接传进去——那等于没设超时，慢请求可能 hang 住进程不退出
超时时间设 5 秒够不够？别拍脑袋
5 秒是电商类接口的常见起点，但不是万能值。它代表“最多等多久，之后强制断开”，设短了会误杀正常慢请求（如支付回调、大文件上传），设长了又拖慢滚动更新节奏。
- 如果用了长轮询或 WebSocket，
Shutdown()不管连接类型，只等 handler 返回——得自己在 handler 里检查ctx.Done() - 务必配
ReadTimeout和WriteTimeout（比如15 * time.Second），否则慢客户端能让连接永远不关闭，导致超时失效 - 验证方法很简单：起服务后发一个
curl "http://localhost:8080/ping" &（带time.Sleep(6 * time.Second)），再 Ctrl+C，看进程是否真退出（ps aux | grep yourapp）
最容易被忽略的泄漏点：非 HTTP goroutine
Shutdown() 只管 HTTP server，不管你的业务 goroutine。定时任务、消息消费者、健康上报、Redis 订阅……这些全得自己关。
- 所有长期运行的 goroutine 必须接收
context.Context，并在select中监听ctx.Done() - 数据库连接池、Redis 客户端、gRPC 连接等，必须显式调
Close()，GC 不会帮你等它们清空队列 - 用
defer关资源容易出错：如果Shutdown()卡在等某个 goroutine，defer根本不会执行——关资源的逻辑得和关机信号同步触发
实际关机流程里，最常卡住的地方不是 HTTP server，而是你忘了关的 ticker、没设 cancel 的 goroutine、或者没 Close 的 Redis client。信号一来，先停业务 goroutine，再等 HTTP 请求收尾，最后才释放资源——顺序错了，就永远退不出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
