Beego 无运行时热补丁能力，其“热重启”实为 bee 工具监听文件变更后触发的进程级重启；必须用 bee run 启动，配合标准项目结构、兼容版本及 bee.json 扩展 watch_ext 才能生效。
Beego 没有运行时热补丁能力，所谓“热重启”本质是 bee 工具监听文件变更后触发进程级重启 —— 这不是魔法，而是编译型语言下的务实方案。
bee run 是热重启生效的唯一前提
直接执行 go run main.go 或运行已编译二进制，完全不会触发任何自动重启。只有用 bee run 启动，bee 才会启动文件监听器并接管构建流程。
- 确保项目根目录下存在
conf/app.conf和标准controllers/目录结构，否则 bee 可能无法识别为 Beego 项目 - bee 版本需 ≥ 1.4.1（对应 Beego ≥ 1.6.0），旧版存在监听遗漏或 panic 风险
- 若终端无任何输出变化，先检查是否误用了
go run；再确认 bee 是否在项目根目录执行
修改 .tpl/.conf/.js 后不重启？补全 bee.json 配置
默认只监听 .go 文件，控制器逻辑改了会重启，但模板或配置变了却没反应——这是常见困惑点。解决方式是在项目根目录加 bee.json：
{
"watch_ext": ["go", "conf", "tpl", "html", "js", "css"]
}
-
watch_ext是白名单，不是通配符；漏写conf就不会响应app.conf修改 - 静态资源（如
static/js/下的文件）也需显式加入列表，bee 不会递归扫描子目录类型 - 修改
bee.json后需手动重启bee run，它不会热加载自身配置
重启后 Session 丢失？别怪 bee，要换 Session 存储方式
每次重启都是全新进程，内存态 Session（memory provider）必然清空。这不是 bug，是机制决定的。
- 开发期最快解法：在
conf/app.conf中设sessionprovider = file，Session 写入本地文件，跨进程可读 - 若用
redisprovider，需确保 Redis 服务常驻且配置正确（sessionproviderconfig = 127.0.0.1:6379） - 切勿在开发期依赖
memoryprovider 做登录态调试，否则你会反复登出并怀疑人生
语法错误导致重启卡死？看终端最后一行错误即可定位
bee 在编译失败时会停住监听，不再响应后续保存。典型现象是：改完代码、保存，但终端静默，浏览器刷新仍是旧内容。
- 错误日志一定出现在终端最末尾，通常是类似
./controllers/user.go:12: undefined: xxx的 Go 编译报错 - 修复后只需再次保存任意一个
.go文件，bee 就会继续尝试构建 - 高频陷阱：新增 controller 未加
import，或拼错 struct 字段名，Go 编译器不会容忍
真正容易被忽略的是：bee 的“秒级重启”依赖本地磁盘 I/O 和 Go 构建速度，当项目引入大量第三方包或启用 -gcflags="-l" 等调试选项时，延迟可能升至 5 秒以上——这时你得盯紧终端日志里的 [INFO] Restarting，而不是凭感觉刷新页面。
