Buffalo 已于 2022 年 12 月正式归档，不再维护，不兼容新 Go 版本，其强耦合设计与微服务需求相悖，API 模式名不副实，构建产物臃肿，任务调度机制不可靠，配置与运维能力缺失，长期维护成本远高于 Gin 等现代框架。
Buffalo 不适合新项目，尤其不适合微服务、API 服务或生产级后台系统——它已于 2022 年 12 月正式归档，不再维护。
Buffalo 已停止维护，且设计与现代 Go 工程实践冲突
官方仓库在 GitHub 上标记为 archived，所有 issue 和 PR 均已关闭。这不是“暂时休眠”，而是明确终止：没有安全更新、不修复 CVE、不兼容新版本 Go（如 1.23+ 的 net/http context 行为变更）。更关键的是，它的核心设计（强耦合模板、内置 pop ORM、全局中间件栈）与微服务的数据自治、轻量通信、可观测性要求直接相悖。你用它起步越快，后期拆分、替换、调试的成本越高。
buffalo new --api 生成的项目不是真正可用的 API 内核
所谓 --api 只是删了部分前端文件，但底层仍加载 HTML 渲染器、模板引擎（plush）、静态文件中间件、CSRF 保护等 Web 专用模块。实测发现：app.Serve() 启动后仍会扫描 templates/ 目录并预编译空模板；c.Render(200, r.JSON(...)) 内部仍经过 HTML fallback 检查路径；middleware.Automatic 会无差别注入 session、cookie、CSRF 等中间件，无法按路由关闭。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- API 响应延迟比 Gin 高 3–4 倍，尤其在高并发下 GC 压力明显上升
-
buffalo build产出二进制含未使用的 JS/CSS/HTML，体积常超 30MB，无法塞进scratch镜像 - Kubernetes readiness probe 因冷启动慢（>5s）频繁失败
grifts/ 不是任务调度器，别把它当 worker 用
grifts/ 是同步脚本执行机制，buffalo task send:email 运行完才返回终端——它不持久化、不重试、不并发、不支持延迟。试图在 grifts/ 里起 goroutine 跑 cron，会被 CLI 进程退出强制终止；硬塞进 buffalo dev 启动流程，则热重载时 goroutine 反复中断、日志混杂、内存泄漏。
真要调度任务，必须外接：
- 用
github.com/hibiken/asynq或github.com/go-co-op/gocron单独起 worker 进程 - 在 action 中 publish 消息到 Redis/RabbitMQ/NATS，由独立服务消费
- 绝不在
grifts/里写for { time.Sleep(); doWork() }
配置、路由、优雅退出全靠自己补洞
Buffalo 不提供多环境配置加载（config/environments/ 不存在），GO_ENV=production 只控制 debug 日志开关，不会自动加载 .env.production；路由注册靠反射遍历 actions/ 目录，无法动态加载或灰度；app.Shutdown() 是对 http.Server.Shutdown() 的浅封装，但中间件不传 context.Context、没设 ReadTimeout，长连接会卡住退出。
这些不是“可选优化”，而是上线前必须手动重写的基础能力。你最终写的不是业务代码，而是 Buffalo 的补丁代码。
如果你只是想快速跑通一个本地 demo 或教学示例，buffalo new 确实能省半小时；但只要涉及接口联调、CI/CD、容器部署、长期维护，Buffalo 就会从“加速器”变成“减速带”。现在用 Gin + sqlx + viper + asynq，三小时搭出的结构，比 Buffalo 三天调出来的更稳定、更易测、更容易换人接手。
