buffalo dev启动失败90%非代码问题，而是环境未对齐：必须在含actions/、models/、buffalo.yaml的根目录执行；启动前需完成go mod tidy、buffalo db create/migrate、数据库服务运行；端口3000被占或GO_ENV未导出会导致静默失败。
buffalo dev 启动失败，90% 不是代码问题，而是环境没对齐。 它不是“进目录就跑”的命令，而是一套强依赖预设状态的开发流程。直接执行却卡住、无输出、或 panic 退出，大概率卡在数据库、端口、路径或环境变量上。
buffalo dev 必须在项目根目录下执行
它只认包含 actions/、models/、buffalo.yaml 的那一层目录。进错目录会报 no app found，而不是提示你“请换目录”。
- 用
ls -d actions models buffalo.yaml确认当前目录是否同时存在这三项 - 别在子目录（如
myapp/actions）里试——即使buffalo dev能运行，后续迁移、模板加载也会出错 -
buffalo new myapp生成后，必须cd myapp再操作，不能跳过
buffalo dev 启动前必须完成的三件事
它不负责初始化数据库、不拉依赖、不建表。这些都得手动做完，否则访问页面时直接 panic。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 先跑
go mod tidy：CLI 生成的go.mod缺少子依赖（比如github.com/gobuffalo/pop/v6），不补全会导致buffalo db migrate失败 - 再跑
buffalo db create和buffalo db migrate：哪怕不用 DB，也得让 pop 初始化成功；若中途失败，migration 表可能变脏，建议先buffalo db rollback -a清空再重试 - 最后确保数据库服务已运行：PostgreSQL 要监听
5432，MySQL 监听3306，SQLite 不需要服务但需路径可写——buffalo dev不会自动拉起 DB 进程
buffalo dev 静默失败的两个高频原因
它遇到某些错误不会明确报错，而是卡住、无输出、或直接退出，容易误判为“程序挂了”。
- 端口
:3000被占：它不会提示“端口冲突”，而是静默失败；加-p 4000快速验证，看是否立刻启动成功 -
GO_ENV=development没生效：这个变量必须在命令前导出，例如GO_ENV=development buffalo dev；写在.env文件里默认不加载，也不会报错
buffalo dev 启动后浏览器打不开 / LiveReload 失效
页面能加载但不自动刷新，或控制台报 WebSocket 连接失败，通常不是前端问题，而是服务端中间件干扰了响应流。
- 检查
app.Use()或app.Middleware.是否插入了修改响应头、提前 write 或 hijack 连接的中间件 - LiveReload 依赖
X-Forwarded-For、Upgrade、Connection等 header，被中间件删掉或覆盖就会断连 - 如果用了反向代理（如 nginx），要确认它转发了 WebSocket 协议升级请求，否则
/livereload会返回 404 或 502
真正容易被忽略的是：buffalo dev 的行为受 buffalo.dev.yml 控制，但改完这个文件必须重启命令才生效——热重载不监听它。还有，assets/ 被删后，watcher 仍会尝试初始化 webpack，导致卡在 npm install 或报 webpack not found，此时应加 --skip-assets 参数绕过。
