buffalo dev 启动失败常见原因包括：项目不在根目录、数据库未启动、migration 表脏、端口3000被占、go_env未导出、热重载路径不匹配、livereload被中间件干扰等。
buffalo dev 启动失败的常见原因
直接运行 buffalo dev 却卡住、无输出或报错退出，大概率不是代码问题，而是环境准备没到位。它依赖完整的项目结构和预设状态，不是“随便进目录就能跑”的命令。
- 必须在项目根目录下执行——即包含
actions/、models/、buffalo.yaml的那层，否则会提示no app found - 数据库服务（如 PostgreSQL 或 SQLite）必须已启动且可连通；
buffalo dev不会自动拉起 DB，只负责启动 Web 服务 - 若之前执行过
buffalo db migrate但中途失败，migration 表可能处于脏状态，导致下次buffalo dev访问数据库时 panic；建议先用buffalo db rollback -a清空再重试 - 端口
:3000被占用时不会报错提示，而是静默失败；加-p 4000指定端口可快速验证是否为端口冲突
GO_ENV=development 不生效？检查三个硬性前提
GO_ENV 是 Buffalo 运行时判断环境的核心开关，但它不是“设了就管用”。很多调试问题源于它根本没被正确读取。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
-
GO_ENV必须在buffalo dev命令执行前导出，例如：GO_ENV=development buffalo dev；写在.env文件里默认不加载 - 确认
app.Env是否真为"development"：在actions/app.go的app.New()后加一行log.Printf("env: %s", app.Env)，启动后看日志输出 - 如果用了自定义
config/env.go，确保其中Development字段有实际值（比如硬编码的 DB URL），而不是空结构体；否则即使app.Env == "development"，连接也会失败
热重载不触发？别忽略 assets/watcher 的隐式依赖
buffalo dev 的热重载能力来自内置的文件监听器，但它只盯特定路径和文件类型。改了某些地方，它根本不会重启。
- 它默认监听
actions/、models/、locales/和templates/下的变更；改main.go或go.mod不会触发重载——这些属于构建入口，需手动重启 - 如果你删了
assets/（纯 API 项目常用操作），watcher 仍会尝试初始化 webpack 相关逻辑，可能卡在npm install或报webpack not found；此时应运行buffalo dev --skip-assets - 某些 IDE（如 VS Code）的文件保存策略（如 atomic write）会导致 inotify 事件丢失；可临时用
touch actions/home.go手动触发一次重载来验证 watcher 是否工作
浏览器打不开 / LiveReload 失效？查中间件与响应头
页面能加载但不自动刷新，或控制台报 WebSocket 连接失败，通常不是前端问题，而是服务端中间件干扰了响应流。
-
buffalo dev默认注入plugins.LiveReload()中间件，它会在 HTML 响应末尾插入一段 JS 脚本；但如果前面某个中间件（比如自定义 gzip 或 CORS）提前调用了WriteHeader()，这段脚本就会被截断 - 检查
actions/app.go中是否误启用了plugins.Gzip()—— 开发期不需要，且它与 LiveReload 冲突 - 若你用 Nginx 反向代理了
localhost:3000，务必透传Upgrade和Connection头，否则 LiveReload 的 WebSocket 升级请求会被拒绝
buffalo dev 就表现异常，但错误提示往往藏在日志深处或根本不输出。
