beego 无运行时热补丁能力，其“热重载”实为 bee 工具监听文件变更后自动重启进程；必须用 bee run 启动，配合 bee.json 配置 watch_ext 扩展监听类型，并修复语法错误才能实现秒级反馈。
Beego 没有运行时热补丁能力，所谓“热更新”实际是 bee 工具监听文件 + 重启进程的组合动作；只要用对命令、配对文件类型、避开编译错误，就能稳定获得秒级反馈。
必须用 bee run 启动，否则热重载不生效
Go 程序一旦启动就固化在内存里，go run main.go 或直接执行二进制都不会触发自动重启。只有 bee run 会启动监听器并接管构建流程。
- 确保项目根目录下有
conf/app.conf和controllers/目录，否则bee可能无法识别为 Beego 项目 - 如果终端提示
not a beego application，检查main.go是否调用了beego.Run()，且项目结构是否符合标准 MVC - Windows 下若报
'bee' is not recognized，确认%GOPATH%\bin已加入系统PATH，且bee version能正常输出
bee.json 扩展监听后缀，模板和配置修改也能触发重启
默认只监听 .go 文件，改个 .tpl 或 .css 不会重启——这不是 bug，是默认行为。要覆盖它，就在项目根目录建 bee.json：
{
"watch_ext": ["go", "conf", "tpl", "html", "js", "css"]
}
-
watch_ext是唯一必需字段，值为字符串数组，不支持通配符（如"*.js"无效） - 添加
"conf"后，改conf/app.conf里的runmode或httpport也会触发重启，适合快速切换开发/测试配置 - 不要加
"log"或"tmp"这类生成文件后缀，否则可能因频繁写入导致无限重启循环
语法错误会让 bee 卡住，必须手动修复再保存
遇到修改控制器后终端没反应、浏览器刷新仍是旧内容，第一反应不是工具坏了，而是代码编译失败了。此时 bee 会停在错误日志并保持旧进程运行（或退出），不会强行重启。
- 典型错误包括：未使用的变量、缺少
return、括号不匹配、import 未引用的包 - 终端通常会打印类似
./controllers/user.go:12:9: undefined: xxx的信息，定位到行号修完再保存即可恢复监听 - 如果用 VS Code，建议开启
"go.toolsEnvVars": { "GO111MODULE": "on" }，避免因模块路径问题误报错
会话丢失不是配置问题，而是进程重启的必然结果
用默认的 memory session provider 时，每次重启都会清空所有登录态——这不是 bug，是设计使然。想保留会话，必须换持久化后端。
- 开发期最轻量方案是切到
file：在conf/app.conf中设sessionprovider = file，无需额外依赖 - 若已部署 Redis，直接配
sessionprovider = redis和sessionproviderconfig = "127.0.0.1:6379"即可 - 别试图在
bee.json里加"session"到watch_ext——session 数据存在内存或外部存储里，不靠文件监听维持
真正容易被忽略的是：热重载的延迟不是网络或磁盘问题，而是 Go 编译本身耗时。哪怕只是改一行 fmt.Println，也要经历 parse → type check → compile → link → exec 全流程；项目越大，这个“秒级”越可能变成 2–4 秒。接受这个事实，比调优配置更实际。
