buffalo dev启动失败主因是数据库未创建、静态资源未构建或端口被占却忽略提示；须先执行go mod tidy、npm install及buffalo db create && buffalo db migrate。
buffalo dev 启动失败的常见原因
直接运行 buffalo dev 却卡住、报错或访问不到 http://127.0.0.1:3000，大概率不是命令写错了，而是前置条件没满足：
- 数据库还没创建：Buffalo 不会自动建库，
buffalo dev启动时若 models 初始化失败（比如连接myapp_development但库不存在），会 panic 并退出，错误里常带database "myapp_development" does not exist - 静态资源没构建：assets/ 下的 JS/CSS 没编译，
buffalo dev会尝试调用npm run build，但若没装 Node 或node_modules缺失，就卡在 “building assets” 步骤不动 - 端口被占但没注意提示：CLI 真的会自动换端口（比如从 3000 → 3001），但它只在终端第一行输出一次
Starting application at http://127.0.0.1:3001—— 很多人盯着原来那行 3000 刷新，其实服务早跑在别处了
启动前必须执行的三个命令
Buffalo 项目不是 go run main.go 那种单文件启动，它依赖三步串联：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
-
go mod tidy：拉取所有 Go 依赖（包括 buffalo、pop、plush），确保models和actions能正常 import -
npm install（或yarn install）：安装前端构建工具链，否则buffalo dev无法生成/public/assets/下的打包文件 -
buffalo db create && buffalo db migrate：先建库，再跑迁移。注意buffalo db create读的是database.yml里的配置，但实际连库靠的是models.NewDB()返回的连接，所以得确认环境变量（如DB_URL）没覆盖错
buffalo dev 的实际监听行为
它不是简单地 go run + webpack watch 两层叠加，而是统一协调：
- 默认监听
actions/、models/、templates/、assets/四个目录；改其中任一文件，都会触发全量重建（Go 二进制 + 前端 bundle） - 不监听
config/下的app.go或routes.go—— 这些改了必须手动重启，因为它们属于应用初始化阶段逻辑，热重载无法安全介入 - 如果加了
--api标志新建的项目，assets/和templates/目录根本不存在，buffalo dev就不会尝试构建前端，启动更快，也不会报 webpack 相关错误
编辑器里调试时 buffalo dev 为什么总断开
VS Code 或 GoLand 调试时点「Debug」，buffalo dev 经常自己退出，这不是 bug，是设计使然：
-
buffalo dev是一个进程管理器，它 fork 出真正的 Web server 进程（myapp二进制），然后监听文件变化决定是否 kill + restart 子进程 - 当你用 IDE 附加调试器到子进程时，
buffalo dev主进程可能因信号处理或超时判定“子进程异常”，主动终止它 - 真要调试，应该直接
go run -gcflags="all=-N -l" main.go，绕过buffalo dev，并在main.go里加断点——buffalo dev只适合日常开发，不适合深入调试逻辑
localhost，但本地跑的是 Docker 容器，实际该填 host.docker.internal；或者 go.mod 里 buffalo 版本锁得太死，和当前 CLI 不兼容，导致 buffalo dev 启动时加载 actions.App() 失败却只报一行模糊的 “panic: interface conversion”。这些细节不看日志根本发现不了。 
