Buffalo框架需手动实现纯内存、毫秒级响应的/health路由：在app.go中Use()链前注册裸handler，返回200 OK字符串，禁用中间件、模板渲染和外部调用，并在Kubernetes探针中统一路径、设initialDelaySeconds:10、timeoutSeconds:1。
Buffalo 框架本身不提供内置健康检查探针扩展，必须手动实现 HTTP 端点并配合 Kubernetes 或反向代理做探针集成。 它不像 Spring Boot Actuator 或 go-zero 那样自带 /healthz 或 /actuator/health。所谓“安装扩展”，其实是添加一个轻量、无副作用的路由 handler，并确保它不被中间件干扰、不依赖未就绪资源。
怎么加一个可靠的 /health 路由
Buffalo 的健康端点必须是纯内存判断、零外部调用、毫秒级响应——否则会被 Kubernetes 的 livenessProbe 因超时直接 kill。最安全的做法是在 app.go 里注册一个裸 handler：
- 在
actions/app.go的app.Use()链之前（避免被 logger、auth 等中间件拦截），插入： app.GET("/health", func(c buffalo.Context) error { return c.Render(200, r.String("OK")) })- 不要用
c.Render(200, r.JSON(...))，避免触发模板渲染或 JSON 序列化开销 - 不要在该 handler 里读环境变量、查数据库、调下游服务——哪怕加了
context.WithTimeout也不行，Kubernetes 默认超时仅 1 秒
为什么不能复用现有中间件或插件
常见错误是试图把健康检查塞进已有中间件逻辑，比如在 metrics 或 auth 中间件里加分支判断路径。这会带来三个实际问题：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 中间件执行顺序不可控：若
app.Use(AuthMiddleware)在 health 路由注册前，/health会被要求登录，返回 401 而非 200 - panic 恢复机制干扰：Buffalo 默认 recover 中间件会捕获 panic 并返回 500，但健康端点一旦 panic 就彻底失联，无法区分是框架崩溃还是业务异常
- 日志/指标打点污染：如果 health 路由走 metrics 中间件，会导致延迟统计虚高、QPS 噪声增大，影响真实接口观测
Kubernetes 探针配置要点
有了 /health 路由，还需正确配置 YAML，否则探针永远失败：
-
livenessProbe和readinessProbe必须用相同路径，例如都设为httpGet.path: /health；不要一个用/health、一个用/readyz，Buffalo 不自动提供后者 - 务必设置
initialDelaySeconds: 10：Buffalo 启动时要加载模板、连接 DB、初始化缓存，前几秒内/health可能还没注册好 -
timeoutSeconds建议设为1（默认值），和 Buffalo handler 的实际耗时匹配；设成 3 或 5 容易掩盖阻塞问题 - 避免用
tcpSocket：Buffalo 没有“端口监听成功即健康”的语义，TCP 连通 ≠ 路由已注册 ≠ 应用就绪
真正容易被忽略的是：Buffalo 的 buffalo dev 模式下，/health 路由虽能访问，但 Kubernetes 探针不会走本地回环，所以必须在 buffalo build --static 后用容器验证；且生产镜像中要确保 APP_ENV=production，否则某些中间件行为（如 debug 日志）可能拖慢响应。
