根本原因是{{template}}引用的子模板未被ParseFiles显式加载；Go模板不自动递归解析，需一次性传入所有依赖文件，如ParseFiles("layout.html","header.html","post.html","footer.html")。
template.ParseFiles 为什么总报 template: "xxx" is undefined
根本原因不是文件没找到，而是模板里用了 {{template "header"}} 这类嵌套调用，但被引用的子模板（比如 header.html）压根没被 ParseFiles 加载进去。
Go 的 html/template 不会自动递归扫描 {{template}} 引用的文件——它只加载你显式传进 ParseFiles 的那一组路径。
- 正确做法：把所有用到的模板文件一次性全传进去，比如
t, err := template.ParseFiles("layout.html", "header.html", "post.html", "footer.html") - 偷懒但可靠的方式：用
filepath.Glob批量收集，template.ParseFiles(globbed...)，避免漏文件 - 如果模板分散在子目录，注意路径必须是相对
ParseFiles调用位置的，不是相对当前 Go 文件；建议统一用./templates/xxx.html这种显式前缀
如何让 template.Execute 渲染出真实 HTML 而不是转义后的字符串
html/template 默认把所有 .Content、.Title 这类字段值当成纯文本处理，自动转义 、<code>& 等字符——这对防止 XSS 是好事，但对静态站生成器来说，经常要原样插入 Markdown 渲染结果或手写 HTML 片段。
- 安全解法：用
template.HTML类型包装原始字符串，比如data.Content = template.HTML(mdRender(text))，再传给Execute - 别用
text/template替代——它不校验 HTML 结构，容易产出非法标签，后续浏览器解析或 SEO 工具会报错 - 注意：一旦用了
template.HTML，你就得自己确保内容可信；Markdown 渲染器要选支持输出安全 HTML 的（如goldmark配WithRendererOption(html.WithUnsafe())）
静态资源路径怎么在模板里写才不会本地预览和部署后路径错乱
直接写 /css/main.css 看似简单，但当站点部署到子路径（比如 https://example.com/blog/）时，浏览器会去根目录找 CSS，404。
立即学习“go语言免费学习笔记（深入）”；
- 最稳方案：生成时注入一个
BaseURL字段到每个模板数据中，模板里统一用{{.BaseURL}}/css/main.css - 不要依赖
os.Getwd()或runtime.Caller动态推路径——构建环境、工作目录、模块路径三者可能完全不一致 - 如果用 Hugo/Jekyll 风格的
{{"{{ .Site.BaseURL }}"}}占位符再替换，容易和 Go 模板语法冲突；改用[[.Site.BaseURL]]这类自定义分隔符更安全
并发执行 template.Execute 时 panic: concurrent map iteration and map write
典型诱因：多个 goroutine 共享同一个 *template.Template 实例，并同时调用 Execute ——虽然文档说 Execute 是并发安全的，但前提是模板没被修改过。而如果你在循环中反复调用 t.New("page-1").Parse(...)，就等于在往模板的内部 map[string]*Template 里写数据，这就触发了竞态。
- 正确模式：提前用
template.Must(t.Clone())为每个页面生成独立副本，再各自Execute - 或者更轻量：所有页面共用一个顶层模板，用
t.Lookup("post.html").Execute(...)，只要不调New/Parse就不会改内部状态 - 用
go build -race跑一遍生成流程，能立刻暴露这类问题；别等上线后随机崩
template.FuncMap 注册时机、以及 Execute 返回的 io.Writer 是否要手动 flush ——这些点看着零碎，但实际卡住进度的时候，往往就卡在这三处。 
