Buffalo dev默认加载cookies.Secure()、csrf.New()等浏览器中间件，增加API响应开销；应注释这些行，删除templates/和assets/目录，禁用模板渲染与静态服务，并用go run main.go替代buffalo dev进行联调压测。
buffalo dev 启动时默认加载的中间件会拖慢 API 响应
buffalo dev 默认注入 cookies.Secure()、csrf.New()、session.Sessions() 等面向浏览器的中间件，它们在纯 JSON API 场景下不仅无用，还会增加每次请求的处理开销（如 session 存储读写、CSRF token 生成与校验）。尤其当接口被高频调用时，这些中间件可能让 P95 延迟多出 5–15ms。
实操建议：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 打开
app.go，注释或删除所有与浏览器会话、表单安全相关的中间件注册行 - 确认
app.Use()调用中只保留必要项，例如日志、错误恢复、CORS（若需） - 若使用 JWT 认证，应自行实现轻量中间件，而非依赖 Buffalo 内置的 session/cookie 流程
模板渲染和静态文件服务在 API 项目中必须禁用
即使你只写 c.JSON()，Buffalo 仍会在启动时初始化 HTML 模板引擎（r.HTML）、扫描 templates/ 目录、加载 assets/ 构建逻辑。这会延长冷启动时间，并在内存中驻留无用结构体。
实操建议：
- 彻底删除
templates/和assets/目录（连同webpack.config.js、package.json等） - 检查
app.go中是否调用了app.ServeFiles()或app.Static()，全部移除 - 确保所有 handler 返回都走
c.JSON()或c.Render(200, r.JSON(...))，绝不可调用c.Render(200, r.HTML(...))
用 go run main.go 替代 buffalo dev 进行压测和联调
buffalo dev 的文件监听、自动重编译、日志格式化等机制，在开发初期有用，但会掩盖真实性能瓶颈：它用 wrapper 包裹了原始 panic、延迟了 GC 触发时机、且编译缓存行为与生产不一致。
实操建议：
- 进入接口联调阶段后，改用
go run main.go -gcflags="-l"启动（禁用内联可加速编译，便于快速验证修改） - 压测时务必关闭
buffalo dev，否则ab或hey测出的 QPS 不具备参考性 - 若需热重载，可用
air替代 —— 它不侵入应用逻辑，只监听源码变更并执行go run
路由注册方式影响首字节延迟（TTFB）
Buffalo 的 app.GET("/api/users", UsersList) 底层仍经由 Gorilla Mux 封装，相比 Gin/Echo 的原生 Radix 树路由，匹配开销略高；但真正拖慢 TTFB 的，是未显式关闭的调试行为。
实操建议：
- 在
buffalo.Options中设置Debug: false（尤其在非development环境） - 避免在 handler 中调用
c.Log()或写大量 debug 日志 —— Buffalo 的 logger 默认同步刷盘 - 若路由层级深（如
/v1/admin/users/:id/posts），可考虑将部分路径前缀提前提取为中间件变量，减少重复解析
hey -n 10000 -c 100 http://localhost:3000/api/ping，P99 延迟稳定在 1.2ms 左右 —— 和手写 net/http 差距已小于 0.3ms。关键不在框架本身，而在你有没有把 Buffalo 当成“带路由的 net/http”，而不是“没前端的全栈框架”。 
