Beego 本身不支持运行时替换控制器，所谓“热更新”实为 bee run 监听文件变化后自动重启进程；它通过 fork 子进程、检测 .go 等文件变更、kill 旧进程并启动新进程实现开发期高效反馈，但会丢失内存 session，且需标准项目结构和 bee.json 配置扩展监听。
Beego 本身不支持运行时替换控制器，所谓“热更新”其实是 bee run 监听文件变化后自动重启进程——它不是真正的 hot reload，但对开发体验足够有效。
为什么 bee run 能“热更新”，而 go run main.go 不行
因为 bee 是一个带监听逻辑的 CLI 工具：它启动时会 fork 一个子进程运行你的 Beego 应用，并在后台持续扫描项目目录下的文件变更。一旦检测到 .go 文件被保存，就 kill 掉旧进程、重新编译并启动新进程。
go run 没有监听能力，每次改完都得手动 Ctrl+C + 再敲命令，效率低且容易漏。
- 必须用
bee run启动，不能用go run main.go或先go build再执行二进制 - 项目结构要标准：必须有
conf/app.conf、controllers/、routers/router.go等目录，否则bee可能无法识别为 Beego 项目 - Beego 版本 ≥ 1.6.0 + bee ≥ 1.4.1 才稳定支持该机制；低于此版本可能监听失效或 panic
如何让模板（.tpl）、配置（.conf）修改也触发重启
默认情况下，bee 只监听 .go 文件。如果你改了 views/index.tpl 或 conf/app.conf，服务不会自动重启，页面可能还是旧的——这是新手最常踩的坑。
解决办法是在项目根目录加一个 bee.json 文件，显式声明要监听的扩展名：
{
"Dir": ".",
"WatchExts": [".go", ".tpl", ".conf", ".html", ".js", ".css"],
"ExclDirs": ["node_modules", "vendor"]
}
-
WatchExts是关键字段，不写它，其他配置都白搭 - 添加
.tpl后，修改模板文件就能立刻看到效果，不用手动刷新+清缓存 - 注意
ExclDirs要排除大目录，否则监听开销高、响应变慢，尤其在 IDE 自动保存频繁时
bee run 重启时会丢会话（session）吗
会。因为它是杀进程再启新进程，所有内存态数据（包括默认的内存 session、未持久化的 cache）都会丢失。
这不是 bug，是机制决定的。如果你依赖 session 登录态做开发调试，会发现一改代码就登出。
- 开发期可接受，但别误以为线上也能这么搞
- 如需保持登录态，得把 session 存到 Redis 或数据库，而不是用 Beego 默认的
memoryprovider - 检查
conf/app.conf中的sessionprovider = memory—— 这行就是罪魁祸首 - 临时 workaround：把
sessionon = false关掉，或者只在 debug 模式下启用 session
热更新失败常见报错和排查点
最典型的是改完保存，控制台没反应，或者报错后卡住不动。常见原因集中在路径、权限和配置三块：
- 当前终端工作目录不是项目根目录（即含
main.go和conf/的那层），bee run会找不到配置 - Windows 下杀进程失败导致端口被占，错误信息类似
listen tcp :8080: bind: address already in use—— 手动taskkill /f /im bee.exe再试 -
bee.json格式错误（比如多了一个逗号、用了中文引号），会导致监听静默失效，建议用 JSON 验证工具过一遍 - Go module 开启状态下，如果项目不在
$GOPATH/src里，且没正确初始化go mod init，bee可能编译失败
真正麻烦的不是“怎么开热更新”，而是“它什么时候不工作、为什么没反应”——这些边界情况比功能本身更值得盯紧。
