Buffalo 项目开发需严格遵循三步闭环：执行 go mod tidy 补依赖、npm install 装前端依赖、先 buffalo db create 再 migrate 建库跑迁移；跳过任一环节将导致 buffalo dev 启动失败或运行报错。
Buffalo 项目开发流程不是“写完代码就跑”，而是围绕 buffalo dev 的热重载机制、go mod 依赖管理、pop 数据库迁移三者联动运转的闭环。跳过任一环节，buffalo dev 都会卡在启动阶段或运行时报错。
buffalo dev 启动前必须完成的三步不可省略
Buffalo 的开发服务器不会帮你补依赖、建库、跑迁移——它只负责监听和重启。常见报错如 "table users does not exist" 或 "cannot find module github.com/gobuffalo/pop/v6"，基本都源于这三步没走全：
- 执行
go mod tidy：补全go.mod中缺失的子依赖（尤其是pop/v6、plush），否则models.NewDB()初始化失败 - 运行
npm install（即使删了assets/）：buffalo dev默认尝试调用 Webpack，找不到node_modules会直接退出，不给你机会进路由层 - 先
buffalo db create再buffalo db migrate：二者顺序不能颠倒；SQLite 用户需确保系统已装gcc，否则sqlite3驱动编译失败，buffalo db命令直接 panic
修改代码后 buffalo dev 不生效的常见原因
它监听的是文件变更事件，但只对特定目录敏感。以下改动不会触发自动重建：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 改
database.yml：该文件不被 Buffalo 运行时读取，真正起作用的是models.NewDB()中解析的环境变量（如DB_URL），改完要手动重启 - 改
config/env.go中的AppPort：这个值只在首次生成时写入，后续修改需加-p参数或删掉.buffalo.dev.yml让它重新生成 - 改
public/下静态文件：默认不监听，除非你显式在app.ServeFiles()中注册路径，否则浏览器缓存会掩盖真实改动
从原型到联调，何时该停用 buffalo dev
它适合快速验证路由结构和模板渲染，但不适合调试逻辑细节。一旦进入接口联调阶段，建议切回 go run main.go：
-
buffalo dev会捕获 panic 并返回 HTML 错误页，掩盖原始 stack trace；而go run直接打印 panic 到终端，定位更快 - 它自动注入 LiveReload 脚本，干扰 Postman/curl 测试；
go run输出纯 HTTP 响应，无副作用 - 若你用了自定义构建流程（如
air或fresh），buffalo dev的 watcher 会与之冲突，导致重复编译或端口占用
真正的开发节奏是：用 buffalo dev 快速搭出路由骨架和页面跳转 → 改用 go run main.go 深度调试 handler 逻辑与数据库交互 → 上 CI 时统一用 buffalo build 打包。别让一个命令绑架整个流程。
