Beego热重载并非框架内置功能，而是bee工具通过监听文件变化、自动构建并重启进程实现的快速开发体验；它不支持运行时热补丁，会中断会话且仅适用于开发环境。
beego 热重载不是框架功能，而是 bee 工具的行为
Beego 本身不提供运行时热补丁或控制器热替换能力。所谓“热重载”，实际是 bee 工具监听文件变化后，自动执行 go build + 杀掉旧进程 + 启动新进程的组合操作。它不修改正在运行的 Go 进程，也不做任何代码注入——本质是快速重启。
这意味着：会话中断、内存状态丢失、长连接断开都是正常现象；它适合开发调试，不能用于生产环境的“无感升级”。
- 必须用
bee run启动，不能用go run main.go或手动go build && ./app - 项目必须在
$GOPATH/src下（Beego 1.x）或启用GO111MODULE=off（若坚持用 GOPATH 模式） -
bee版本需 ≥ 1.4.1，beego≥ 1.6.0，Go ≥ 1.5；v2 版本请确认安装的是github.com/beego/beego/v2，而非已归档的astaxie/beego
bee run 不生效？检查这三处硬性路径约定
bee run 启动失败或不监听变更，90% 是因为项目结构/路径不符合 Beego 的硬编码查找逻辑。
- 当前工作目录下必须存在
conf/app.conf，且该文件不能是空的（至少含appname = myapp） - 必须有
routers/router.go，且其中的init()函数里调用了beego.Router或beego.Get等注册函数 - 控制器文件需放在
controllers/目录下，结构体嵌入*beego.Controller，方法名首字母大写（如Get、Post）
例如，若把 router.go 放错位置，或漏写 init()，bee run 虽然能启动，但所有请求返回 404，且修改控制器代码也不会触发重启——因为 bee 检测到项目“无法正确加载”，会静默跳过监听。
想改 .tpl/.conf 也触发重启？加 bee.json 配置文件
默认情况下，bee 只监听 .go 文件。模板（.tpl）、配置（.conf）、静态资源（.js、.css）修改后不会触发重启，需要手动刷新浏览器或重启服务。
在项目根目录新建 bee.json，内容如下：
{
"Dir": ".",
"WatchExts": [".go", ".tpl", ".conf", ".html", ".js", ".css"],
"ExcludedDirs": ["node_modules", "tmp"]
}
注意：WatchExts 是扩展名列表，不是 glob 模式；ExcludedDirs 可避免监听 node_modules 导致卡顿。改完保存，bee run 会自动重载该配置（无需重启 bee 进程）。
bee run 启动慢、监听延迟高？别忽略 GOPATH 和模块冲突
常见现象：改完代码等 3–5 秒才看到终端输出 “restarting…”；甚至修改后完全没反应。这通常不是 bee 性能问题，而是环境配置冲突。
- Windows 用户确认
%GOPATH%/bin在系统 PATH 中，且杀毒软件没拦截bee.exe创建子进程 - 混用
$GOPATH/src和go mod：如果GO111MODULE=on，又把代码放在$GOPATH/src下，bee可能因找不到go.mod而降级为传统构建，或加载错误依赖版本 - 推荐做法：统一用 modules 模式 —— 删除
$GOPATH/src下的项目，直接在任意路径初始化go mod init myapp，再go get github.com/beego/beego/v2，最后确保bee是 v2 兼容版（bee version输出含 v2）
真正影响热重载体验的，从来不是 bee 本身，而是 Go 构建链路是否干净、路径是否被硬编码绑架、以及你有没有在无意中绕过 Beego 的约定。
