buffalo dev 热加载需同时满足三条件：CLI ≥v0.18.0、根目录含 buffalo.dev.yml 或 main.go 调用 app.Serve()、终端路径为项目根目录；否则静默失败。
buffalo dev 就是热加载的唯一入口，不需要额外装插件、改构建脚本或配环境变量——但三件事没做对，它就完全不工作。
buffalo dev 启动前必须满足的三个硬性条件
它不是“有代码就能跑”的命令，缺一不可：
-
buffaloCLI 版本 ≥ v0.18.0：运行buffalo version确认；旧版不监听文件变更，升级用go install github.com/gobuffalo/cli/v2@latest - 项目根目录下存在
buffalo.dev.yml或main.go中调用了app.Serve()：二者任一即可，缺了会静默失败，终端无报错也无服务 - 当前终端路径必须是项目根目录：即同时包含
actions/、models/、go.mod和buffalo.yaml（或buffalo.dev.yml）的那层目录；进错子目录会报no app found
修改代码后不重启？先看它监听哪些路径
默认只监听 actions/、models/、templates/、locales/ 四个目录下的 Go 或模板文件；改其他地方根本不会触发重建：
- 改
app.go、main.go、go.mod、config/env.go：不监听，必须手动Ctrl+C再buffalo dev - 新增了
ui/components/或lib/这类自定义目录：加参数--watch-dir ./ui/components，可重复使用多次 - 模板里用
{{ partial "header.html" }}引用了partials/header.html：得把partials/也加进--watch-dir，否则改了 partial 没反应 - 用了
go:embed加载静态资源：embed 文件不在监听范围，得手动touch actions/home.go“骗”一次重启
常见静默失败现象和快速验证法
它不报错、不提示、不卡死，而是直接退出或卡在 Starting application... ——这时候别猜，按顺序验证：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 终端执行
touch actions/home.go：如果触发重启，说明 watcher 工作正常，问题出在你改的文件路径或类型上 - 启动时加
-p 4000：绕过端口冲突（:3000被占时它可能静默失败而非提示） - 确认没同时跑
air、fresh或自定义go:generate：它们和buffalo dev的内部 watcher 冲突，会导致进程卡死或 asset 构建无限挂起 - 删了
assets/目录却卡在Building assets：加--skip-assets参数跳过前端流程（v1.0.1+ 支持）
LiveReload 不自动刷新页面？这不是热加载失效
热重载成功 ≠ 页面自动刷新。后者依赖浏览器端 WebSocket 连接，容易被干扰：
立即学习“go语言免费学习笔记（深入）”；
- 没装 LiveReload 浏览器插件：改完模板只会重启服务，页面不会 reload —— 这是预期行为，不是 bug
- 中间件删了
Upgrade或Connectionheader：比如自定义日志中间件调用了c.Response().Header().Del("Upgrade")，会断开 LiveReload 握手 - 用 VS Code Remote-SSH 或 Docker 开发：终端显示
Listening on http://127.0.0.1:3002，但这是远程机本地地址；需手动访问http://[host]:3002，并确保防火墙放行该端口
buffalo dev 的热加载本质是进程级重启 —— 每次都会 kill 旧进程、编译新二进制、拉起新服务。这意味着内存 session 清空、DB 连接池重置、全局变量重初始化。别指望它像前端 HMR 那样保留状态。 
