Gin渲染HTML模板失败主因是工作目录与模板路径不匹配及模板名不一致。LoadHTMLGlob路径相对于运行命令所在目录，c.HTML()模板名须与磁盘文件路径完全一致（含大小写、后缀），数据字段名需严格匹配且导出。
Gin 渲染 HTML 模板失败，90% 是因为模板没加载成功或路径不对——不是代码写错了，是工作目录和加载方式没对上。
LoadHTMLGlob 路径必须相对于启动时的当前工作目录
你写 r.LoadHTMLGlob("templates/**/*")，Gin 就真的只认「运行命令所在目录」下的 templates/。哪怕 main.go 在 cmd/server/ 里，只要你在项目根目录执行 go run cmd/server/main.go，它就去根目录找 templates/，而不是 cmd/server/templates/。
- 用
go run main.go启动？确保终端在main.go所在目录 - 用 IDE（如 GoLand）？检查 Run Configuration → Working directory 设置，别让它默认指向 GOPATH 或项目根以外的位置
- 不确定当前工作目录？加一行
log.Println(os.Getwd())在r := gin.Default()后面立刻打印出来 - 推荐统一用
r.LoadHTMLGlob("templates/**/*")，支持子目录，比templates/*.html更可靠
c.HTML() 渲染时模板名必须和文件路径完全一致
模板文件叫 templates/reset_password.html，那 c.HTML() 第二个参数就得传 "reset_password.html"，不能少后缀、不能加路径前缀（除非你用了 {{define}} 并显式命名）。
- Gin 不会自动补
.html，传"reset_password"就是 404 - 如果模板在子目录，比如
templates/auth/reset.html，渲染时必须写"auth/reset.html"（前提是LoadHTMLGlob("templates/**/*")已加载） - 文件名大小写敏感：Linux/macOS 下
Reset_Password.html和reset_password.html是两个文件 - Windows 上可能“碰巧”不报错，但部署到 Linux 服务器就挂——别依赖这个
数据字段必须导出且键名严格匹配模板中的 {{.Key}}
gin.H{"email": "a@b.com"} 传进模板，模板里写 {{.Email}} 就取不到值——Go 的 struct 字段必须首字母大写才可导出，gin.H 是 map[string]interface{}，但模板取值仍按 key 名字字面匹配，区分大小写。
立即学习“前端免费学习笔记（深入）”；
- 模板中写
{{.email}}，传gin.H{"email": "a@b.com"}才能生效 - 如果用结构体传值，字段必须大写：
type ResetData struct { Email string }，模板里才能用{{.Email}} - 嵌套字段如
{{.User.Email}}，要求User字段可导出，且其类型也有可导出的Email - 空值或 nil 字段不会报错，但渲染结果为空字符串——建议开发时加
{{if .email}}{{.email}}{{else}}[missing]{{end}}快速定位
模板语法错误不会编译报错，但会导致空白页或 panic
比如漏写右括号 {{.email、误用 {{.Email}}（但数据里只有 email）、或在 {{range}} 里忘了 {{end}}，Gin 默认不会提前校验，而是等到真正渲染时才出问题。
- 启用调试模式：
gin.SetMode(gin.DebugMode)，能让模板解析失败时返回详细错误（如 “unexpected EOF”） - 把模板文件后缀统一用
.html，避免 Gin 内部因扩展名判断跳过解析 - 复杂逻辑尽量拆成小模板 +
{{define}}+{{template}}，单个文件别堆太多嵌套 - 上线前务必关掉
DebugMode，否则模板错误会暴露完整路径和变量名
最容易被忽略的是工作目录和模板名的双重严格性：它既不猜路径，也不容错拼写，连大小写都卡死。调试时先确认 os.Getwd() 和文件系统里的真实路径是否一致，再核对 c.HTML() 传的字符串和磁盘上文件名是否逐字相同——这两步过了，剩下基本就是数据传参的事了。
