os.Exit() 会导致 Kratos 服务无法优雅退出，因为它会立即终止进程，跳过 defer、runtime 清理、app.Stop() 及所有注册的 cleaner/closer，造成连接泄漏、数据丢失和信号未响应。
为什么 os.Exit() 会导致 Kratos 服务无法优雅退出
Kratos 的优雅退出依赖于 app.Stop() 触发所有注册的 cleaner 和 closer，比如关闭 gRPC server、DB 连接池、Redis 客户端等。直接调用 os.Exit(0) 会跳过 defer、runtime cleanup 和 app 生命周期钩子，导致连接泄漏、数据丢失或信号未响应。
常见现象：收到 SIGTERM 后进程立即消失，lsof -i :port 仍能看到残留连接；Prometheus 指标上报中断；MySQL 连接数持续上涨。
- 永远不要在
main()或 signal handler 中写os.Exit() - Kratos 内置了信号监听（默认捕获
SIGINT/SIGTERM），无需手动signal.Notify() - 若需扩展信号处理（如
SIGHUP重载配置），应通过app.WithSignal()注册，而非覆盖默认逻辑
如何正确注册自定义 cleaner 和 closer
优雅退出的核心是让资源释放逻辑被 Kratos 的 app.Stop() 调用链自动触发。必须使用 app.WithCleaner() 或 app.WithCloser() 注册函数，不能靠全局变量或 init() 里硬编码关闭逻辑。
示例场景：关闭自定义的 Kafka consumer group、释放内存缓存、等待异步任务完成：
app := kratos.New(
kratos.Name("user-service"),
// 注册清理函数：Stop() 时按注册逆序执行
kratos.WithCleaner(func(ctx context.Context) error {
return kafkaConsumer.Close() // 阻塞直到 consumer 停止拉取
}),
kratos.WithCloser(func(ctx context.Context) error {
return cache.Shutdown(ctx) // 带超时的缓存 flush
}),
)
-
WithCleaner()用于同步/轻量清理（如关闭 listener、cancel ctx） -
WithCloser()用于可能耗时的操作（如 DB 连接池 Close、HTTP client shutdown），支持传入context.Context控制超时 - 两个函数都应在返回前确保资源真正释放，否则
app.Stop()会阻塞直至超时（默认 15s）
app.Run() 返回后是否还需手动 Stop？
不需要。Kratos 的 app.Run() 是阻塞调用，内部已封装信号监听 + 自动 Stop 流程。当它返回时，意味着 Stop 已完成或超时强制退出。
错误写法：
if err := app.Run(); err != nil {
log.Fatal(err)
}
app.Stop(context.Background()) // ❌ 多余且危险：Stop 可能已被调用两次
正确做法是只关注 Run 的返回值，用于判断启动失败（如端口被占），而非退出流程：
if err := app.Run(); err != nil {
log.Errorw("app run failed", "error", err)
os.Exit(1) // ✅ 此处 os.Exit 合理：仅用于启动失败，不涉及优雅退出逻辑
}
-
app.Run()返回 ≠ 服务挂了，而是生命周期结束（正常退出或被信号终止） - 日志中看到
app is stopping...表示优雅退出流程已触发 - 若 Run 返回很快（毫秒级），大概率是启动阶段 panic 或配置错误，不是优雅退出
如何验证优雅退出是否生效
最直接的方式是观察进程退出前的行为，而非只看是否“没报错”。重点检查三件事：连接是否关闭、goroutine 是否回收、日志是否有关键提示。
- 启动服务后，用
lsof -i :8000 | wc -l记录初始连接数；发送kill -TERM $(pidof your-app)，几秒后再查，应归零或只剩 TIME_WAIT - 在 cleaner/closer 函数里加
log.Info("closing kafka...")，确认这些日志出现在app is stopping...之后、进程退出之前 - 用
pprof抓 goroutine：启动时curl "http://localhost:8000/debug/pprof/goroutine?debug=2" > before.txt，退出前再抓一次比对，确认无残留 worker goroutine - 数据库连接池可设
SetMaxOpenConns(1)并在 cleaner 里db.Close()，然后观察 MySQL 的SHOW PROCESSLIST是否清空
最容易被忽略的是 cleaner/closer 函数内部未做 context 超时控制——比如一个卡住的 http.Client.Do() 会让整个 Stop 阻塞满 15 秒才强制杀掉，期间服务看似“没反应”，其实正在死等。
