buffalo框架需自定义中间件实现请求耗时统计：在app.use()链靠前位置插入，用time.now()在c.next()前后打点计算差值，存于局部变量或context，避免全局变量并发错乱；不可依赖不可靠的c.time。
Buffalo 框架里怎么加请求耗时中间件
Buffalo 默认不记录请求耗时，得自己加中间件。核心思路是用 time.Now() 在请求开始和结束时打点，差值就是处理时间。别用全局变量存开始时间——并发下会错乱，必须存在 c.Request().Context() 或直接用局部变量。
实操建议：
- 在
app.go的app.Use()链中插入自定义中间件，位置要靠前（比如放在csrf.New之前），否则可能漏统计中间件自身开销 - 不要在中间件里直接写日志到文件或网络——高并发下 I/O 会拖慢整个请求链；优先写到结构化日志（如
logrus.WithField("duration_ms", dur.Milliseconds())）再由统一日志系统处理 - 注意 Buffalo 的
Abort()和Render()调用后仍会走后续中间件，所以耗时统计逻辑必须包裹整个next(c)调用，不能只包 handler
为什么 c.Time 不适合做耗时统计
Buffalo 的 c.Time 是 context deadline 时间戳，不是请求开始时间。它可能被 timeout 中间件修改，也可能为空，完全不可靠。真实耗时必须自己捕获。
常见错误现象：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 所有请求都显示
duration_ms: 0—— 因为用了未初始化的c.Time - 耗时数值忽大忽小甚至负数 —— 因为混用了不同请求的
c.Time值（比如在 goroutine 里异步取） - 部分请求没记录 —— 因为把计时逻辑写在了某个特定 route 的 handler 里，漏了 404 或中间件 panic 场景
如何让耗时统计兼容 JSON API 和 HTML 请求
Buffalo 的 c.Response() 在不同渲染模式下行为一致，但响应头/体内容差异大。耗时统计本身不依赖渲染方式，但附加信息（比如往响应头塞 X-Response-Time）要注意：HTML 请求通常不关心这个头，而 API 客户端可能依赖它做监控。
实操建议：
- 统一在中间件末尾设置
c.Response().Header().Set("X-Response-Time", fmt.Sprintf("%.2f", dur.Seconds()))，所有类型请求都生效 - 如果要往 JSON 响应体里加字段（如
{"data": ..., "meta": {"duration_ms": 12.3}}），必须判断c.Request().Header.Get("Accept")是否含application/json，且仅对c.Render()成功返回的 JSON 类型生效；否则 HTML 页面会吐出非法 HTML - 避免在中间件里调用
c.Render()或c.JSON()—— 这会提前结束响应，导致后续中间件和 handler 失效
耗时统计对性能有影响吗
单纯两次 time.Now() + 减法 + 日志结构化，单次开销在纳秒级，对 QPS > 1k 的服务基本无感。真正拖慢的是日志落地动作，尤其是同步写磁盘或远程 HTTP 上报。
容易被忽略的地方：
- 开发环境开启详细耗时日志没问题，但生产环境建议只对 P95 以上长尾请求采样（比如
if dur > 500*time.Millisecond再记录） - Buffalo 的
Logger默认是同步的，若用logrus，记得配logrus.SetOutput(&logrus.Logger{})并启用异步 hook（如logrus_sentry或自研 channel + goroutine） - 别在耗时中间件里做任何阻塞操作：查数据库、调外部 API、生成 trace ID（除非你确定它已预生成）——这些会让本该快的请求变慢，还污染统计基线
