根本原因是$GOPATH/bin未加入PATH或Go版本低于1.21；需执行go version确认≥1.21，go env GOPATH确认非空，再检查$PATH是否含$GOPATH/bin，缺失则添加export PATH="$GOPATH/bin:$PATH"并写入shell配置文件，最后新开终端运行buffalo version验证。
buffalo: command not found 怎么办
根本原因不是没装，而是二进制没进 PATH 或 Go 环境不达标。执行 go version 必须 ≥ go1.21；低于此版本，go install 会静默失败或生成不可用的二进制。
确认 go env GOPATH 输出非空，然后检查 $GOPATH/bin 是否在 $PATH 中：echo $PATH | grep -o "$GOPATH/bin"。若无输出，需手动追加：export PATH=$GOPATH/bin:$PATH，并写入 ~/.zshrc 或 ~/.bash_profile。
安装命令必须是：go install github.com/gobuffalo/cli/cmd/buffalo@v0.18.1（注意：@latest 已失效，仓库归档，proxy 不缓存新 tag）。
装完新开终端再试 buffalo version；如果仍报错，大概率是 GOPATH/bin 没生效，或之前装过旧版残留冲突。
buffalo new 报错退出的常见触发点
buffalo new 对项目目录极其敏感，不是“有空文件夹就能跑”。
- 当前目录不能已有
go.mod—— 否则框架无法识别模块路径，直接 panic - 目录必须为空（不含
.git、README.md等任何文件），否则 CLI 会拒绝初始化 - 若你已手动
go mod init myapp，请删掉go.mod和go.sum，再跑buffalo new myapp - 加
--api --skip-yarn可绕过前端依赖和模板引擎校验，大幅降低首次失败概率
buffalo dev 启动后访问 404 或 panic 的真实原因
表面是路由或服务没起来，实际常卡在三处底层衔接上：
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
-
buffalo db create和buffalo db migrate没执行 →models.NewDB()连接后查表即报table not found -
public/目录不存在 →buffalo dev默认启用 packr2，所有/assets/xxx路径返回 404；建个空public/或放public/.keep即可 - 数据库连接实际走的是环境变量
DB_URL，不是config/database.yml—— 配对了 yml 文件但忘了设DB_URL=postgres://...，就会连空库甚至 panic
终端最后一行会显示真正监听的地址（比如 Listening on http://127.0.0.1:3001），别只认默认 :3000。
插件加载失败、卡在 plugins install 阶段
这是 2026 年 Buffalo 最典型的“伪故障”：CLI 尝试加载已归档的 github.com/gobuffalo/buffalo-plugins，必然失败。
唯一有效解法是启动前设置环境变量：BUFFALO_PLUGIN_CHECK=false。不设这个，buffalo dev 会在初始化阶段无限等待或直接 panic。
该变量必须在运行 buffalo dev 前生效，临时加的话用：BUFFALO_PLUGIN_CHECK=false buffalo dev。
注意：这个 flag 不影响模型生成、迁移、路由注册等核心能力，只是跳过已失效的插件发现逻辑 —— 它本来就没必要在现代 Go 环境中运行。
