c.HTML()仅将模板渲染结果写入HTTP响应体并发往浏览器，不生成磁盘文件；如需落地为真实HTML文件，须手动用html/template与bytes.Buffer捕获输出并调用os.WriteFile保存。
gin.HTML() 本身不生成静态 HTML 文件
很多人误以为 c.HTML() 会把渲染结果写入磁盘，其实它只是把模板执行后的 HTML 字符串写进 HTTP 响应体，发给浏览器。服务端内存里不留痕，硬盘上更没文件。想落地为真实 .html 文件，必须手动捕获输出并写盘。
用 html/template + bytes.Buffer 捕获渲染结果
核心思路是绕过 Gin 的响应流程，直接调用 Go 标准库的 template.Execute()，把结果暂存在 bytes.Buffer 中，再保存到文件系统：
- 先用
template.ParseFiles()或template.New().Parse()加载模板（注意路径要对） - 创建
bytes.Buffer，调用t.Execute(buf, data)渲染 - 用
os.WriteFile()把buf.Bytes()写入目标路径，比如"output/index.html" - 别忘了处理错误：模板语法错、数据字段缺失、磁盘满、权限不足都会导致失败
示例关键片段：
tmpl := template.Must(template.ParseFiles("templates/index.tmpl"))
buf := new(bytes.Buffer)
err := tmpl.Execute(buf, gin.H{"Title": "首页", "Now": time.Now()})
if err != nil {
log.Fatal(err)
}
os.WriteFile("output/index.html", buf.Bytes(), 0644)
静态页面生成适合预构建场景，不适合实时请求
在 HTTP 处理函数里边收请求边生成 HTML 文件并返回，听起来可行，但实际踩坑多：
- 并发写同一文件会冲突（比如两个用户同时访问
/build），得加锁或用唯一文件名 - 频繁磁盘 I/O 拖慢响应，失去 Gin 高性能优势
- 生成的文件谁来清理？要不要按时间轮转？线上没人手动删
- 如果模板里有动态数据（如用户 ID、实时时间），生成的“静态页”立刻就过期
真正合理的做法是：把它做成构建脚本（make build-static），在 CI/CD 流水线或本地部署前跑一次，产出纯静态站点丢到 Nginx 或 CDN 上——这才是“静态页面生成”的本意。
别混淆 gin.Static() 和静态页面生成
gin.Static("/static", "./dist") 只是让 Gin 对指定目录下的已有文件提供 HTTP 服务，它不参与任何模板渲染，也不生成新文件。你传进去什么，它就原样吐出来。如果你希望用户访问 /index.html 看到的是模板渲染结果，那得走 c.HTML()；如果你希望用户访问 /index.html 看到的是提前生成好的、磁盘上真实存在的 index.html，那就得用 gin.StaticFS() 包裹一个自定义 http.FileSystem，或者干脆换用 net/http.FileServer —— 但这就脱离了 Gin 模板体系。
