Buffalo 项目必须执行 go mod tidy，否则 pop/v6、packr/v2 等关键子依赖不会被拉取，导致启动时 panic；go.mod 仅声明顶层依赖，tidy 才能补全实际运行所需的所有间接依赖并更新 go.sum。
Buffalo 项目不能只靠 go mod init 或自动生成的 go.mod 就跑起来——必须手动执行 go mod tidy，否则 pop/v6、packr/v2 等关键子依赖不会被拉取，启动直接 panic。
为什么 go mod tidy 不可跳过
Buffalo CLI 生成的 go.mod 只声明顶层依赖（如 github.com/gobuffalo/buffalo），不包含实际运行所需的子模块。比如数据库驱动注册依赖 github.com/gobuffalo/pop/v6，模板渲染依赖 github.com/gobuffalo/plush，静态资源打包依赖 github.com/gobuffalo/packr/v2，这些都不会自动出现在 go.sum 中。
- 不执行
go mod tidy就跑buffalo dev，常见错误是panic: unknown dialect "postgres"或cannot find module "github.com/gobuffalo/packr/v2" - Git 拉新分支或切换 tag 后，必须重新运行
go mod tidy，IDE 的自动补全不可信 - 若项目引用私有模块，需提前设置
GO_PRIVATE=*.yourcompany.com，否则tidy会卡在认证环节
go mod tidy 必须和 npm install 配合使用
Buffalo 是双栈项目：Go 层负责路由与数据库，Node.js 层负责 assets 编译。两者依赖互不替代，缺一不可。
- 只跑
go mod tidy：Webpack 找不到node_modules，buffalo dev报exec: "npm": executable file not found in $PATH或静默退出 - 只跑
npm install：Go 运行时找不到pop.Connection，初始化 model 时 panic - 推荐用
yarn install --frozen-lockfile --network-concurrency 16替代npm install，尤其在国内网络下更稳 - Docker 构建时，
RUN npm install必须放在COPY . .之后、buffalo dev之前
database.yml 中的变量名必须带 APP_ 前缀
Buffalo 使用 github.com/gobuffalo/envy 加载环境变量，但它**只识别以 APP_ 开头的变量**。写成 DB_PASSWORD 或 DATABASE_URL 是无效的。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 正确写法：
url: ${APP_DATABASE_URL}，然后在 shell 中导出APP_DATABASE_URL="postgres://..." - 错误写法：
url: ${DATABASE_URL}→envy完全忽略，连接时抛出password authentication failed for user "postgres" - 验证方式：在
actions/app.go初始化处加log.Printf("DB URL: %s", os.Getenv("APP_DATABASE_URL")) - 若必须兼容旧变量名，改用
os.LookupEnv("DB_PASSWORD")显式读取，绕过envy
CI/CD 和本地开发的一致性要点
很多 CI 失败是因为用了 go mod download 替代 go mod tidy，或误以为 GO_ENV=production 可以延迟设置。
-
go mod download不校验依赖图一致性，可能导致本地能跑、CI 报undefined: pop.NewConnection -
GO_ENV是编译期常量，必须在buffalo build前设好，写成buffalo build && GO_ENV=production buffalo start已经晚了 - SQLite 用户注意：
go mod tidy成功不代表驱动可用；系统必须已安装gcc，否则go build阶段会因sqlite3编译失败而中断 - 插件如
buffalo-pop不进go.mod，它通过 CLI 全局安装，不影响tidy结果，但缺失会导致buffalo db命令不可见
最常被忽略的是：每次 git pull 后，go.mod 文件可能没变，但子依赖版本已更新——这时不 tidy，就等于用旧二进制跑新逻辑，panic 往往来得毫无征兆。
