Beego 本身不支持 .tpl 模板运行时热加载，修改后需重启服务；但通过配置 bee.json 添加 "tpl" 到 watch_ext，可触发 bee 自动监听并重启，实现伪热更新。
Beego 本身不支持前端模板（.tpl）的运行时热加载，修改后必须重启服务才能生效；但通过 bee 工具监听模板文件变更并自动重启，可实现“伪热更新”效果——这是当前唯一稳定、开箱即用的开发方案。
为什么修改 .tpl 文件后页面没变？
Beego 的模板引擎在启动时一次性加载并编译所有 .tpl 文件到内存，后续请求直接复用已编译的模板对象。即使你改了文件，进程内缓存不会自动刷新，也不会触发重新解析。
常见错误现象：
- 保存
views/index.tpl后刷新浏览器，内容仍是旧的 - 控制台无任何日志输出，
bee run进程未重启 - 误以为是 Beego 配置问题，反复调整
beego.BConfig.WebConfig.TemplateLeft等参数，无效
让 .tpl 修改触发自动重启：配置 bee.json
默认情况下，bee 只监听 .go 文件，.tpl 不在其 watch 列表中。需显式扩展监听范围：
立即学习“前端免费学习笔记（深入）”；
- 在项目根目录（与
main.go同级）创建bee.json - 写入以下内容（注意逗号和引号格式）：
{
"watch_ext": ["go", "tpl", "conf", "html"]
}
保存后，bee run 会自动读取该配置——无需重启 bee 进程。下次修改任意 .tpl 文件，终端将立即输出类似日志：
[INFO] Restarting myapp [INFO] ./main is running [I] http server Running on :8080
模板路径与 reload 行为的几个关键点
Beego 模板加载依赖 beego.BConfig.WebConfig.ViewsPath（默认为 views），但 bee 的监听逻辑与该配置无关，它只按文件后缀匹配磁盘路径。因此：
-
bee.json中的"tpl"匹配所有后缀为.tpl的文件，无论是否在views/下 - 若使用
.html作为模板后缀（如views/layout.html），必须把"html"加入watch_ext，否则不触发重启 - 修改
conf/app.conf中的viewspath不影响监听行为，只影响运行时模板查找路径 - 模板语法错误（如漏掉
{{end}}）会导致go build失败，bee将停止重启并打印编译错误，需修复后再次保存
开发期避免频繁重启的替代思路
完全依赖重启对高频模板调试效率偏低，可临时配合以下手段：
- 在控制器中用
beego.LoadAppConfig("ini", "conf/app.conf")+beego.ReloadTemplates()手动重载（仅限 dev 模式，且需自行封装触发逻辑，非官方推荐） - 将动态片段抽离为
include子模板，缩小单次修改影响范围 - 静态资源（
.css/.js）建议直接由前端构建工具（如 Vite）托管，绕过 Beego 服务，避免干扰模板流程
真正需要“毫秒级模板热更新”的场景，在 Go 生态中目前没有零成本方案——因为模板编译本身是构建期行为，而 Go 没有运行时代码重载能力。接受 1–3 秒重启延迟，是兼顾稳定性与开发体验的合理折中。
