Kratos服务不优雅退出主因是未接管app生命周期：需在WithBeforeStop中立即反注册并重试，再执行Server.Shutdown，且须按依赖反序释放资源、设置超时与连接 draining 参数。
Kratos服务不优雅退出，90%是因为没接管 app 生命周期，而不是框架本身问题。 Kratos 默认的 app.Run 不处理 SIGTERM、不调用 registry.Deregister、也不等 HTTP/gRPC server drain 完连接——它只负责启动。所有退出逻辑必须由开发者显式插入。
为什么直接 kill -15 后服务还在收请求？
根本原因是注册中心元数据没及时清理：K8s 摘除 Endpoints 是秒级的，但 Kratos 服务若没在收到 SIGTERM 后立刻反注册，注册中心（如 Nacos/Etcd）仍会把流量路由过来，直到心跳超时（通常 5–30 秒）。客户端看到的是 Connection refused 或 No instance，不是“服务已下线”。
- 检查点：用
curl http://nacos:8848/nacos/v1/ns/instance/list?serviceName=xxx看实例是否还在列表里 - 常见错误：在
app.WithAfterStop里 deregister —— 太晚了，此时 server 已 shutdown，新请求进不来，但旧连接可能还在传数据，而注册中心还没摘流 - 正确时机：必须在
app.WithBeforeStop第一步执行registry.Deregister，且失败要重试（建议最多 3 秒，指数退避） - 注意：
contrib/registry/nacos的Register和Deregister都不带重试，需自行包装
HTTP/gRPC 连接 draining 总是超时失败？
http.Server.Shutdown 和 grpc.Server.GracefulStop 默认行为太“佛系”：它们只拒绝新连接，但对已建立的 keep-alive、streaming、长轮询连接不做主动干预。一旦有慢 handler 或阻塞 I/O，Shutdown 就卡住，最终触发 SIGKILL 强杀。
- 必须给
http.NewServer显式设置ReadTimeout和WriteTimeout（例如 5 秒），避免单个慢请求拖垮整个 shutdown 流程 - gRPC 服务启用
KeepaliveParams，设MaxConnectionAge（如 20 分钟），让客户端主动重连，减少 shutdown 时待 drain 的连接数 - WebSocket/SSE 这类被
Hijack的连接，Shutdown完全不感知，需用srv.RegisterOnShutdown手动关闭连接池或广播断开事件 - 别用
context.Background()启动后台 goroutine；所有任务必须绑定可取消 context，并在app.WithBeforeStop中 cancel
为什么进程退出后还有残留 goroutine 或文件句柄？
这是资源释放顺序错乱的典型表现：DB 连接池关了，但某个 handler 还在用 *sql.DB；日志器关了，但异步 flush goroutine 还在往已关闭的 fd 写。Kratos 的 app.WithAfterStop 是最后一步，但不是“所有资源都该在这关”。
- 原则：按依赖反序释放。例如：HTTP server → gRPC client → Redis client → DB connection pool → logger
- 检查命令：
lsof -p <pid> | wc -l</pid>若远超正常值（如 >500），说明文件/网络句柄未 close - 用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看是否有阻塞在select或 channel receive 的 goroutine - Kratos 的
app.WithServer注册的服务，其Stop方法必须同步完成；若含异步逻辑（如等待队列清空），需自己加 timeout 控制
真正难的不是写 shutdown 代码，而是厘清“谁先停、谁后停、停不掉怎么办”。Kratos 把契约交给你，它不猜你的 DB 是否 ready、不替你判断 streaming 连接是否真 idle、也不帮你 retry deregister——这些决策点，恰恰是线上稳定性最常出问题的地方。
