Kitex 不自动 recover panic，需在业务 handler 层显式用 defer+recover 或通过 server middleware 统一兜底，且仅对当前 goroutine 有效，无法捕获 Thrift 底层解码等非 handler 阶段 panic。
recover 本身不是 Kitex 的配置项，它无法通过 YAML 或中间件注册开关“一键开启”。Kitex 作为 Go 微服务框架，其 panic 恢复必须由开发者在 业务 handler 层显式插入 defer+recover，或在 自定义中间件中统一包裹。Kitex 不会自动为你 recover，也不会跨 goroutine 生效。
Kitex HTTP/Thrift handler 中必须手动加 defer+recover
Kitex 的服务端 handler（比如 HandlerFunc 或实现 xxxService 接口的方法）一旦 panic，若未捕获，整个 goroutine 会崩溃，Kitex 默认不兜底——它把恢复责任交还给业务层。
常见错误写法：
func (s *MyServiceImpl) Echo(ctx context.Context, req *api.EchoRequest) (*api.EchoResponse, error) {
// 这里直接 panic，没 recover → 请求协程挂掉，客户端卡死或超时
panic("unexpected nil pointer")
}
正确做法（每个 handler 自行防护）：
- 使用匿名
defer包裹核心逻辑 -
recover()必须在defer函数体内调用 - 返回明确的错误（如
kitex.Error或自定义 error），避免裸 panic
func (s *MyServiceImpl) Echo(ctx context.Context, req *api.EchoRequest) (*api.EchoResponse, error) {
var resp *api.EchoResponse
var err error
defer func() {
if r := recover(); r != nil {
// 记录日志，避免静默失败
klog.CtxErrorf(ctx, "panic recovered: %v", r)
// 转为业务错误返回，客户端可感知
err = kitex.NewTransError(kitex.UnknownError, fmt.Sprintf("server panic: %v", r))
}
}()
// 正常业务逻辑（可能 panic）
resp = &api.EchoResponse{Message: req.Message + "!"}
return resp, nil
}
Kitex 中间件里统一加 recover（推荐用于全局兜底）
Kitex 支持 server middleware（kitex.WithMiddleware），适合把 recover 提炼成可复用的中间件，避免每个 handler 重复写。
关键点：
- 中间件函数接收
nexthandler，自己负责调用它 -
recover()必须放在中间件的defer里，且在next()调用之后 - 注意：Kitex 的中间件是同步执行的，
next()返回后才执行 defer，所以 recover 能捕获到next()内部触发的 panic
示例中间件：
func RecoverMiddleware(next endpoint.Endpoint) endpoint.Endpoint {
return func(ctx context.Context, req, resp interface{}) (err error) {
defer func() {
if r := recover(); r != nil {
klog.CtxErrorf(ctx, "kitex recover middleware caught panic: %v", r)
err = kitex.NewTransError(kitex.UnknownError, "internal server error")
}
}()
return next(ctx, req, resp)
}
}
// 注册方式
svr := xxxservice.NewServer(
&MyServiceImpl{},
kitex.WithMiddleware(RecoverMiddleware),
)
⚠️ 注意：这个中间件只对当前 server 的 handler 生效，不影响 Kitex 内部 goroutine（如连接管理、心跳协程等）——那些 panic 仍会导致进程退出。
recover 在 Kitex 里容易踩的坑
-
recover()放在普通函数体里（非defer函数内）→ 总是返回nil -
defer写在 panic 之后 → 来不及注册，panic 直接上抛 - 在子 goroutine 里调用
recover()试图捕获主 goroutine 的 panic → 完全无效（recover只对当前 goroutine 有效） - recover 后继续使用已 panic 的资源（如已 close 的 channel、已释放的锁）→ 状态不一致，可能引发二次 panic
- 把 recover 当 error 处理：用 recover 替代
if err != nil判断 → 违背 Go 错误处理哲学，掩盖可预期错误
Kitex 场景下最易忽略的一点：Thrift 协议层的 panic（如反序列化失败）可能发生在 Kitex 底层 decode 阶段，此时你的 handler middleware 已经错过时机。这类 panic 需要靠 Kitex 的 kitex.WithTransHandler 或自定义 transport.TransHandler 拦截，不属于常规 handler recover 范畴。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
