Revel框架无内置健康检查，需手动注册跳过中间件的裸函数路由；直接复用Controller会触发鉴权、日志等Filter导致401/性能问题；正确做法是在init.go中用InterceptFunc配合Skip:true注册/healthz，并手动设置状态码与Content-Type。
Revel框架没有健康检查内置机制，必须手动实现；直接复用业务控制器或用http.HandleFunc会绕过中间件、丢失上下文、无法注入依赖，且易被鉴权拦截。
为什么不能在现有Controller里加Health方法
Revel的Controller生命周期绑定请求上下文，但健康检查需绕过所有中间件（如JWT、日志、CORS），否则probe可能因401/500被K8s误判为不健康。若塞进ProductController或UserController，路由会经过完整Filter链，导致：
- 鉴权中间件返回401，livenessProbe连续失败触发重启
- 日志中间件打满IO，拖慢响应（健康检查每秒可能被调10+次）
- 无法控制超时——比如DB Ping卡住，整个goroutine阻塞，probe timeout后容器被杀
如何注册独立、无中间件的健康路由
Revel支持InterceptFunc和InterceptMethod，但健康端点必须彻底跳过Filter。正确做法是：在app/init.go中用revel.InterceptFunc注册裸函数，并显式禁用Filter：
func init() {
// 注册 /healthz 路由，跳过所有 Filter
revel.InterceptFunc(healthHandler, revel.BEFORE, &revel.FilterConfig{
Skip: true, // 关键：跳过所有 Filter
})
revel.Router.Add(&revel.Route{
Method: "GET",
Pattern: "/healthz",
Action: "App.Health",
})
}
<p>func healthHandler(c *revel.Controller) revel.Result {
c.Response.Status = "200 OK"
c.Response.ContentType = "application/json; charset=utf-8"
return c.RenderJSON(map[string]interface{}{
"status": "ok",
"timestamp": time.Now().Unix(),
})
}
- 别用
revel.InterceptMethod绑到某个Controller——它仍走Filter链 -
Skip: true是关键，否则Filter会执行，包括你自定义的JWTFilter或LoggingFilter - 响应必须手动设
Status和ContentType，c.RenderJSON()不会自动设200（Revel v1.0+行为）
带依赖检查的/readyz怎么写才不阻塞
Revel不提供context.Context透传到Controller层的标准方式，但健康检查必须防卡死。DB/Redis检查不能用同步db.Ping()，得自己套超时：
func readyHandler(c *revel.Controller) revel.Result {
// 用带超时的 goroutine 检查 DB
done := make(chan error, 1)
go func() {
done <- db.Ping() // 假设 db 是全局 *sql.DB
}()
<pre class="brush:php;toolbar:false;">select {
case err := <-done:
if err != nil {
c.Response.Status = "503 Service Unavailable"
return c.RenderJSON(map[string]string{"status": "down", "reason": "db unreachable"})
}
case <-time.After(2 * time.Second):
c.Response.Status = "503 Service Unavailable"
return c.RenderJSON(map[string]string{"status": "down", "reason": "db check timeout"})
}
c.Response.Status = "200 OK"
return c.RenderJSON(map[string]string{"status": "ok"})}
- 别用
time.Sleep等待——它会阻塞当前goroutine，违反Revel单goroutine per request模型 - 用
select+time.After是唯一安全超时方式，避免probe卡住 - Redis检查同理：用
redisClient.Ping().Err()，但必须包裹在同样结构里 - 不要在
/readyz里做SELECT查询——用Ping()或INFO命令，耗时控制在毫秒级
状态码和响应体容易踩的坑
Revel默认对c.RenderJSON()返回200，但若中途出错（比如panic、Filter abort），可能返回500或空响应。K8s会把500当liveness失败，反复重启容器：
- 绝对不要依赖
c.RenderJSON()自动设状态码——手动写c.Response.Status - 响应体必须极简：
{"status":"ok"}，不嵌套version、uptime等字段（这些属于/metrics，不是健康检查） - 别在健康Handler里调
c.Render()或c.Redirect()——它们会触发模板渲染或302，返回HTML或跳转，被probe判定为异常 - 错误时用
c.Abort("503")而非panic，后者会导致整个App崩溃
真正难的不是写代码，而是让健康检查既快又准：快到不拖慢probe，准到不把假死当健康。Revel没给现成轮子，就得自己控goroutine、管超时、绕Filter——漏掉任一环，K8s都会默默把你服务踢下线。
