Buffalo编译慢的根源在于其build命令未优化go build参数且强制执行冗余流程，提速需绕过CLI、直接使用go build并精简构建步骤。
Go + Buffalo 的编译速度瓶颈不在框架本身，而在 buffalo build 的默认行为：它不控制 go build 参数，也不跳过无用资源扫描和前端构建。提速必须绕过 CLI 封装，直接干预 go build 和 asset 流程。
buffalo build 为什么慢？
它本质是调用 go build，但默认不做任何优化：不设 CGO_ENABLED=0、不加 -trimpath、不传 -ldflags="-s -w"；同时还会强制触发 assets 构建（即使你删了 webpack）、扫描 templates/ 目录、加载 pop ORM 初始化逻辑——这些对纯 API 完全冗余。
- 修改一个
actions/user.go，buffalo dev却重建整个前端、重连数据库、重载模板引擎 -
buffalo build默认打包templates/和assets/，哪怕它们是空的，也会触发 packr 扫描和 embed 初始化 - 没显式指定
GOOS/GOARCH时，它用本地环境构建，CI 中常因平台不一致失败或重编译
用 go build 替代 buffalo build 构建二进制
生产环境应弃用 buffalo build，改用原生 go build 控制全流程。Buffalo 的 Go 代码本身完全兼容标准构建流程，只需确保路由注册和中间件初始化在 App() 前完成即可。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先清理冗余：
rm -rf templates/ assets/ node_modules/ webpack.config.js - 注释掉
app.Use(middleware.PopTransaction)、app.ServeFiles等非 API 必需项 - 执行：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -ldflags="-s -w" -mod=readonly -o ./bin/app ./cmd/app - 注意：
-ldflags必须写成单个参数，-ldflags="-s" -ldflags="-w"只生效最后一个
开发阶段怎么让热重载快起来
buffalo dev 的监听粒度太粗、启动链路太长，不适合 API 开发节奏。真正轻量的方案是用 air 或 reflex 监听关键文件，绕过 Buffalo 的 asset 构建和模板预编译。
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go install github.com/cosmtrek/air@latest - 写
.air.toml，只监听：include_dirs = ["actions", "app.go", "models"]，排除node_modules和assets - 启动：
air -c .air.toml --exec "go run -gcflags='-l' main.go"（-gcflags='-l'关闭内联，提升重启速度） - 禁用 Buffalo 自带的 recovery 中间件，否则 panic 不打堆栈——改用
go run main.go直接调试更准
容易被忽略的兼容性陷阱
Windows 下 -w 无效；CGO_ENABLED=0 在依赖 SQLite 或 OpenSSL 的项目里会直接构建失败；而 buffalo build 会静默忽略这些错误，直到运行时 panic。
- 若项目用了
github.com/mattn/go-sqlite3，必须保留CGO_ENABLED=1，并配好CC环境变量 - CI 中务必验证构建产物：
file ./bin/app看是否为目标平台 ELF；./bin/app version看是否能正常启动 - 别信
buffalo build --static=false能跳过前端——它只是不打包 public/，但依然会尝试运行npm run build，失败就卡住
