必须使用 html/template 渲染 HTML，因其自动上下文感知转义、结构校验和 template.HTML 显式信任机制可防止 XSS；text/template 无转义、不校验、易致漏洞与静默失效。
渲染 HTML 时必须用 html/template，否则 XSS 风险直接落地
如果你在 Go Web 服务中用模板生成网页（比如 index.html），却用了 text/template，那用户提交的 <script>alert(1)</script> 会原样插入页面并执行——这不是“可能”，是必然发生。因为 text/template 完全不转义，它只做字符串替换；而 html/template 在输出变量时自动把 < 变成 、<code>" 变成 "，且能感知上下文：在 href="{{.URL}}" 中做 URL 编码，在 onclick="f('{{.JS}}')" 中做 JS 字符串转义。
- 安全不是可选项：只要输出到浏览器 DOM，就必须用
html/template - 例外只有一种：你明确要生成纯文本（如邮件正文、INI 配置、Shell 脚本）
- 别信“我输入都过滤过了”——模板引擎的上下文感知转义是最后一道防线，不可绕过
html/template 会校验 HTML 结构，text/template 不会
用错包最隐蔽的问题不是 XSS，而是模板静默失效。比如你在 text/template 里写 <div>{{.Content}}</div>，而 .Content 是 "<p>hello</p><img src=x onerror=alert(1)>"，它会原样拼进去，浏览器解析时可能因标签嵌套错乱导致后续 DOM 渲染异常，但模板本身不报错、也不警告。
-
html/template解析模板时就检查标签闭合，若发现<b>xxx没闭合，ParseFiles()直接 panic - 这种提前报错能帮你发现模板语法错误，而不是等上线后用户看到错位页面才排查
- 注意：这个校验只发生在
Parse*阶段，不影响运行时性能
想输出原始 HTML？必须显式标记为 template.HTML
后端拼好的富文本（如 Markdown 渲染结果）、管理后台允许的 HTML 片段，不能靠“关掉转义”来处理——html/template 没有全局 disable 转义的开关。正确方式是：让数据字段类型为 template.HTML，并在模板中用 {{.Content}}（不加任何修饰），或用管道 {{.Content | safeHTML}}（需自行注册该函数）。
- 错误写法：
{{.Content | printf "%s"}}或{{.Content | raw}}—— 这些在html/template中无效，仍会被转义 - 安全前提：仅当内容完全由可信来源生成（如 CMS 后台审核通过的富文本），且不含用户可控字段时，才可标记为
template.HTML - 别在模板里拼接 HTML 字符串：
"<b>" + name + "</b>"→ 类型仍是string，照样被转义
性能差异几乎可忽略，但选错包会让优化白做
两者底层共享同一套解析器，执行效率基本一致。真正影响性能的是使用方式：反复调用 template.ParseFiles()、在模板里做复杂逻辑（如嵌套循环查 DB）、用 reflect 访问深层结构字段。但如果你误用 text/template 渲染 HTML，后续所有性能优化（预编译、缓存、扁平化数据）都掩盖不了一个事实：你的页面天生带 XSS 漏洞。
立即学习“go语言免费学习笔记（深入）”；
- 启动时解析一次，全局复用
*template.Template实例 —— 这对两个包都适用 - 别为了“快一点”换回
text/template：它不比html/template快，只是少做了安全检查 - 第三方模板引擎（如
fasttemplate）适合无逻辑的纯替换场景，但放弃上下文转义能力，不适用于 HTML 输出
最容易被忽略的一点：模板文件扩展名和包选择无关。叫 layout.tmpl 还是 page.html 都不重要，关键是你用哪个包加载它——html/template.Must(template.ParseFiles("page.html")) 才真正启用 HTML 安全机制。
