buffalo需自定义中间件实现性能指标埋点，因框架不内置pprof或prometheus集成；须在路由匹配后注册metricsmiddleware，注意静态资源过滤、panic恢复及prometheus端点适配。
Buffalo 中没有内置的性能指标埋点，得自己加中间件
Buffalo 本身不提供类似 pprof 自动暴露或 prometheus 原生集成的指标采集能力。所有耗时、状态码、路由命中等指标，必须通过自定义中间件手动记录。这不是缺陷，而是框架设计取舍——它把可观测性交由开发者按需接入。
用 buffalo.MiddlewareFunc 拦截请求并打点
最直接的方式是写一个统计耗时和状态码的中间件，在 app.go 的 app.Use() 链中注册。注意两点：一是必须在路由匹配之后（即放在 app.Aware() 之后），否则拿不到 c.Request().URL.Path；二是避免对静态资源（/assets/、/favicon.ico）打点，否则指标会被噪声淹没。
示例代码片段：
func MetricsMiddleware(next buffalo.Handler) buffalo.Handler {
return func(c buffalo.Context) error {
start := time.Now()
err := next(c)
duration := time.Since(start).Milliseconds()
status := c.Response().Status()
// 这里对接你的指标系统，比如 log、statsd、prometheus client
log.Printf("path=%s status=%d duration_ms=%.2f",
c.Request().URL.Path, status, duration)
return err
}
}
然后在 app.go 中启用：
app.Use(MetricsMiddleware)
别漏掉 panic 和 recover 场景下的指标丢失
Buffalo 默认会捕获 handler panic 并返回 500，但这个过程绕过了你写的中间件的 duration 统计逻辑——因为 next(c) 已经 panic，后续代码不执行。结果就是：部分 500 错误在指标里显示为“0ms 耗时”，造成平均延迟虚低。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
解决办法是用 defer/recover 包一层：
- 在中间件内加
defer捕获 panic，手动记录异常耗时和状态码 - 调用
c.Error()或c.Render()显式返回错误响应，避免被框架二次处理 - 确保指标上报逻辑（如
prometheus.SummaryVec.Observe()）在 defer 里也执行
想对接 Prometheus？用 promhttp + 自定义 collector
Buffalo 不自带 /metrics 端点，也不能直接复用 net/http 的 promhttp.Handler()，因为它的路由系统不兼容标准 http.Handler 接口。正确做法是：
- 在
app.go中用app.GET("/metrics", MetricsHandler)注册一个 action - 该 action 内部调用
promhttp.Handler().ServeHTTP()，但要传入 Buffalo 的c.Response()和c.Request() - 提前注册自定义 collector，比如按 path + method 统计的
prometheus.NewSummaryVec
关键点：Buffalo 的 Response 是包装过的，需用 c.Response().Writer 获取底层 http.ResponseWriter，否则 promhttp 会 panic。
真正难的不是写中间件，而是决定哪些维度要保留——比如是否按 controller 分组、是否标记 slow query、是否过滤健康检查接口。这些决策一旦上线就很难回退，得在第一个指标埋点时就想清楚。
