buffalo dev 启动失败90%是环境问题而非代码问题：必须在含actions/、models/、buffalo.yaml的根目录执行；数据库需提前启动并可连通；GO_ENV必须导出且端口3000未被占用；热重载仅监听特定路径变更。
buffalo dev 启动失败，90% 不是代码问题，而是开发环境没对齐——它对目录结构、数据库状态、环境变量、端口和监听路径都有硬性要求，缺一不可。
buffalo dev 必须在项目根目录下执行
它只认包含 actions/、models/、buffalo.yaml 的那层目录。进错目录会直接报 no app found，而不是提示“请换目录”。常见误操作：在 myapp/actions 里敲命令，或把项目解压到带空格的路径（如 ~/My Projects/myapp），后者会导致 watcher 初始化失败。
- 用
ls -A | grep -E "^(actions|models|buffalo\.yaml)$"确认当前目录是否真有这三个关键项 - Windows 用户注意：路径中含中文或 Unicode 字符时，
buffalo dev可能静默退出，改用英文路径重试 - VS Code Remote-SSH 连服务器开发时，确保终端工作路径是项目根目录，不是家目录
数据库服务必须提前启动且可连通
buffalo dev 不拉起数据库，只尝试连接。PostgreSQL 或 MySQL 没跑起来，它会在首次访问页面时 panic，错误堆栈里常出现 connection refused 或 dial tcp 127.0.0.1:5432: connect: connection refused。
- PostgreSQL：运行
pg_ctl -D /usr/local/var/postgres status（macOS Homebrew）或systemctl is-active postgresql（Linux）确认进程存活 - MySQL：用
mysqladmin -u root -p ping测试连通性，别只看systemctl status mysql - SQLite 不支持
buffalo db命令——pop v6+ 已移除 dialect 注册，即使database.yml写了dialect: sqlite3也无效
GO_ENV 和端口冲突是最隐蔽的两个坑
GO_ENV=development 不生效？大概率是变量没导出到子进程，或者被 buffalo.dev.yml 覆盖。端口 3000 被占时，buffalo dev 不报错，而是卡住不动或立即退出，毫无提示。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 验证环境：在
actions/app.go的app.New()后加一行log.Printf("env: %s", app.Env)，启动后看日志输出是否为development - 端口检测：运行
lsof -i :3000（macOS/Linux）或netstat -ano | findstr :3000（Windows）查占用进程 - 快速绕过：用
buffalo dev -p 4000指定端口，再手动访问http://localhost:4000
热重载不触发？先确认改的是它监听的路径
它默认只监听 actions/、models/、locales/、templates/ 下的变更。改 main.go、go.mod、database.yml 或 config/env.go 都不会触发重启——这些属于构建或初始化环节，需手动停启。
- 删了
assets/目录后仍卡在 webpack？加--skip-assets参数：buffalo dev --skip-assets - VS Code 启用 “Atomic Save” 时，inotify 可能收不到事件；临时用
touch actions/home.go手动触发一次重载来验证 watcher 是否活着 -
buffalo.dev.yml里的配置（如port、https）修改后必须重启buffalo dev才生效，热重载不管它
真正卡住人的，从来不是语法或逻辑，而是 buffalo dev 对环境状态的强依赖——它不帮你启动 DB，不自动读 .env（除了 dev 场景），也不容忍路径或端口的微小偏差。每次失败，优先查这四点，比翻日志快得多。
