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。
实操建议：
- 打开
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 触发时机、且编译缓存行为与生产不一致。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
实操建议：
- 进入接口联调阶段后，改用
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），可考虑将部分路径前缀提前提取为中间件变量，减少重复解析
实际压测中，一个剥离了模板、静态文件、CSRF、Session 的 Buffalo API，在 4 核 8G 机器上跑 hey -n 10000 -c 100 http://localhost:3000/api/ping，P99 延迟稳定在 1.2ms 左右 —— 和手写 net/http 差距已小于 0.3ms。关键不在框架本身，而在你有没有把 Buffalo 当成“带路由的 net/http”，而不是“没前端的全栈框架”。
