buffalo 应在构建前精简为纯 go 项目：删前端文件、浏览器中间件、html 渲染、数据库代码；dockerfile 中仅用 go build，禁用 buffalo cli 和命令；确保 app.go 无残留 servefiles 等调用。
buffalo build 会触发 asset 编译，但容器里不该干这事
Buffalo 的 buffalo build 命令默认会执行前端构建（Webpack）、模板编译、迁移文件打包等操作——这些在纯 API 场景下全是冗余动作，且依赖 Node.js 和 Go 工具链共存，极易在 Alpine 或 distroless 镜像中失败。真正该做的，是在构建镜像前就完成 Buffalo 的“骨架精简”，让 go build 成为唯一编译入口。
- 删掉
assets/、templates/、node_modules/、webpack.config.js等所有前端相关目录和文件 - 注释或删除
app.Use(cookies.Secure())、app.Use(csrf.New())、app.ServeFiles()等面向浏览器的中间件和路由 - 确认
app.JSON()或c.Render(200, r.JSON(...))是唯一响应方式，移除所有r.HTML调用 - 把
database.yml和pop相关代码（如pop.Connect()）彻底删掉，除非你真要用 SQL
Dockerfile 里别碰 buffalo CLI，只用 go build
Buffalo 的 CLI 不是运行时依赖，只是项目初始化和开发辅助工具。容器镜像里不需要 buffalo 二进制，也不该在 Dockerfile 中执行 buffalo build。正确做法是：本地完成精简 + go mod vendor（可选），然后在镜像中只做标准 Go 构建。
- 基础镜像优先选
golang:1.23-alpine（编译阶段） +alpine:3.20（运行阶段），避免引入多余包 - 多阶段构建中，build 阶段运行
go build -o /app/myapi ./，不调用任何buffalo命令 - 运行阶段 COPY 编译好的二进制，不 COPY
go.*、actions/源码或buffalo-plugins - 如果用了
samber/do或其他 DI 容器，确保其初始化逻辑在main.go中完成，不依赖 Buffalo 的app.go自动加载机制
buffalo dev 的热重载机制在容器里失效且有害
容器启动后是静态环境，buffalo dev 依赖的文件监听、进程重启、asset 重新编译等能力不仅无法工作，还会因尝试访问不存在的 node_modules 或 webpack 而 panic。更关键的是，它会掩盖真实启动失败原因——比如你忘了删 templates/，buffalo dev 可能静默跳过，而 go run main.go 会直接报错。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 开发阶段用
buffalo dev快速验证路由结构没问题，但进入构建流程前必须切到go run main.go - CI/CD 流水线中禁止出现
buffalo build或buffalo dev，统一用go build -gcflags="-l" -o myapi . - 若需调试 panic，加
-gcflags="all=-N -l"保留符号表，否则 stack trace 会丢失行号
预安装的本质是“不安装”，而是提前裁剪
所谓“预安装”，不是把 Buffalo CLI 打进镜像，也不是在 Dockerfile 里跑 go install github.com/gobuffalo/buffalo/v2@latest。Buffalo 对运行时零依赖——它的路由、context、中间件抽象最终都编译进了你的二进制。真正要预处理的，只有两件事：删掉你不想要的代码，以及确保 go build 能干净通过。
最容易被忽略的一点：Buffalo 生成的 app.go 里常有 app.ServeFiles("/assets", ...) 这类调用，即使你删了 assets/ 目录，这条语句仍会存在，并在启动时尝试读取路径，导致 panic。必须手动清理，不能靠“容器里没装 node 就自动跳过”这种侥幸心理。
