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 把多个生命周期（Go 编译、asset 构建、DB 迁移、HTTP 服务）耦合在一个命令里——只要其中一环没准备好，buffalo dev 就表现异常，但错误提示往往藏在日志深处或根本不输出。