Buffalo 的 buffalo build 不适合生产打包，因其不区分环境、不过滤敏感配置（如 database.yml、.env）、默认嵌入前端资产与模板，并启用调试中间件，导致二进制包含冗余且不安全内容。
Buffalo 项目打包不能直接用 buffalo build 交付生产，它会把未清理的配置、前端资产、模板甚至 database.yml 全部塞进二进制，且默认启用调试中间件——这等于把开发环境整个“冻干”扔进生产。
为什么 buffalo build 不适合生产打包
Buffalo 的 buffalo build 命令本质是封装了 go build + 资源嵌入（packr 或 statik），但它不区分环境、不过滤敏感内容、也不跳过非必要组件：
- 它会把
templates/、assets/、migrations/全部打包进去，哪怕你已删掉这些目录，只要文件还在磁盘上就可能被误嵌入 -
database.yml和.env若未从.gitignore和构建上下文排除，会被读取并硬编码进二进制（尤其旧版 packr 有路径遍历风险） - 生成的二进制默认启用
middleware.Recovery和middleware.Logger，在生产环境会暴露堆栈和请求体 - 打包后仍依赖
os.Getenv()读取配置，但若没设ENV=production，它会 fallback 到 development 模式加载全部中间件
真正安全的打包流程：三步剥离 + 显式构建
生产打包的核心不是“怎么打”，而是“打什么”。必须先清理、再控制、最后构建：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 删除或重命名非必要目录：
rm -rf templates/ assets/ migrations/ grifts/ locales/ docker/（保留actions/、models/、app.go、main.go） - 确认
config/env.go中只通过os.Getenv()读取变量，且所有敏感字段（如DB_PASSWORD）不在代码里硬编码 - 在
app.go中显式禁用模板引擎：app.Templates = nil；移除所有app.ServeFiles和静态路由 - 用标准 Go 构建命令替代
buffalo build：CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o myapi .
容器化部署时的关键检查点
Docker 镜像不是“打包完就完事”，Buffalo 项目容易在镜像层暴露不该有的东西：
- Dockerfile 必须用
multi-stage：第一阶段用golang:alpine编译，第二阶段用scratch或alpine:latest运行，禁止把node_modules/、go.mod、database.ymlCOPY 进最终镜像 - 启动命令必须显式指定环境：
ENV=production PORT=8080 ./myapi，不能依赖.env文件 - 健康检查路径（
livenessProbe）别指向/或带模板渲染的路由，应走纯 JSON 接口如/healthz，避免因Templates == nil导致 panic - 如果用了
pop，确保models/pop.go中的连接初始化逻辑不调用pop.LoadConfig()—— 它会试图解析database.yml，而该文件不应存在于生产镜像中
最常被忽略的一点：Buffalo 打包后仍会尝试加载 public/assets/ 目录下的文件（即使你删了 assets/），只要 app.Use(assets.XXX) 没被注释，就会在启动时报 stat public/assets: no such file。这不是 panic，但会导致 readiness probe 失败——Kubernetes 会反复重启 Pod，而日志里只有一行找不到目录的 warning。
