beego模板默认路径为views且需显式声明，仅识别.tpl扩展名（须调用addtemplateext注册.html等），dev模式下文件变更不生效多因runmode未设为dev、工作目录错误或文件系统监听失效。
Beego 的模板引擎默认就可用，但多数人卡在路径不对、扩展名不识别、开发模式下改了模板没刷新这三件事上。
模板文件放哪？views 目录不是硬编码，但必须显式声明
Beego 不会自动扫描项目根目录下的 views，它只认你通过 beego.SetViewsPath 或配置项指定的路径。默认值是 "views"，但这个“默认”仅在你没调用任何设置函数、也没改配置的前提下才生效。
- 如果你把模板放在
templates/下，必须在main.go里写：beego.SetViewsPath("templates") - 配置文件中写法是：
viewspath = "templates"（注意不是views_path或viewsPath） - 路径必须是相对
os.Getwd()的，启动时工作目录错了，SetViewsPath就会指向空目录，且无报错 - 修改后需重启进程——Beego v2 不支持运行时热切换视图路径
.tpl、.html、.gohtml 都能用，但得提前注册扩展名
Beego 默认只认 .tpl。哪怕你放的是 index.html，不注册扩展名就直接 404 或 panic：「template: index.html: no such template」。
- 在
main.go初始化阶段加一行：beego.AddTemplateExt("html") - 可多次调用注册多个后缀：
beego.AddTemplateExt("gohtml") - 注册顺序无关，但必须在
beego.Run()之前完成 - 注意大小写：Windows 下
.HTML和.html可能被当作不同后缀，统一用小写更稳妥
开发模式下模板不更新？检查 runmode 和文件系统事件监听
Beego 在 dev 模式下确实会每次请求都重新解析模板，但前提是它能感知到文件变化。很多情况下改了 index.tpl 却没生效，是因为：
-
conf/app.conf里runmode = dev没配对，或被环境变量覆盖（如BEED_ENV=prod） - 使用
bee run启动时，若当前目录不是项目根（比如进了controllers/再执行），bee无法正确加载配置，runmode回退为prod，模板就被缓存了 - 某些文件系统（如 WSL2 的挂载卷、Docker Desktop 的 file sharing）会丢弃 inotify 事件，导致 Beego 收不到修改通知——此时只能手动删掉
beego.TemplateCache（不推荐）或强制重启 - 编辑器保存时用了“原子写入”（如 VS Code 默认行为），旧文件被替换成新 inode，而 Beego 还在监听旧文件句柄——关掉编辑器的
files.useExperimentalFileWatcher可缓解
c.TplName 赋值后渲染失败？优先查路径拼接和大小写
Controller 中写 c.TplName = "user/profile.tpl" 看似合理，但 Beego 实际查找的是 views/user/profile.tpl（注意不是 views/user/profile.tpl.tpl）。常见翻车点：
-
TplName值不能带前导斜杠，c.TplName = "/user/profile.tpl"会导致路径解析异常 - Linux/macOS 下文件名大小写敏感：
Profile.tpl和profile.tpl是两个文件，但模板里写{{.Profile.Name}}不会报错，容易误判为数据没传进去 - 如果模板里用了
{{template "header" .}}，被嵌套的header.tpl必须也在同一级views/目录下，或你已用beego.AddViewPath显式添加了额外搜索路径 - 没有
TplName时 Beego 会尝试匹配controllername/methodname.tpl，这个自动推导逻辑在自定义路由（如web.Router("/u/:id", &c.UserController{}, "get:GetProfile")）下容易失效
最常被忽略的是：Beego 的模板缓存是全局 map，一旦某个模板编译失败（比如语法错误），后续所有对该模板的请求都会复用那个 panic 状态，直到进程重启——所以看到奇怪的「template: xxx: nil data」，先 curl -X GET /debug/pprof/goroutine?debug=2 看有没有卡在模板编译 goroutine，再检查最近改过的 tpl 文件。
