template包默认对{{.}}自动转义HTML，但显式使用html函数或template.HTML类型时跳过转义；安全渲染需先用bluemonday清洗再转template.HTML，且必须统一用html/template、设置正确Content-Type头。
template 包默认不自动转义 HTML 字符？
不是默认不转义，而是 template 包严格区分「普通文本插值」和「HTML 插值」——只有用 {{.}} 插入字符串时才会自动 HTML 转义；一旦你显式调用 html 函数（比如 {{.Content | html}}），或使用 template.HTML 类型，它就跳过转义，直接输出原始字符。
这是设计使然，不是 bug。但恰恰是这里最容易出 XSS：开发者误以为“用了 template 就安全”，结果把用户输入塞进 template.HTML 或加了 | safeHtml（实际是 | html）就放行了。
- 常见错误现象：
template: "xss":1:23: executing "xss" at <.userinput>: can't evaluate field UserInput in type string</.userinput>这类报错往往是因为你试图对未导出字段做 HTML 渲染，但更危险的是没报错却渲染了恶意脚本 - 真实使用场景：富文本编辑器内容、评论区带格式的回复、后台 CMS 的页面片段 —— 这些地方常被诱导“必须保留 HTML”，于是开发者手动绕过转义
-
template.HTML是一个类型别名，不是函数，它本身不校验内容；只要类型匹配，template就原样输出，不做任何过滤或清理
如何安全地渲染用户提交的 HTML 片段？
别用 template 包直接渲染不可信 HTML。它不是 HTML sanitizer，也不带白名单机制。真要渲染，得先清洗，再转成 template.HTML。
推荐组合：用 github.com/microcosm-cc/bluemonday 做预处理，再交给 template：
立即学习“go语言免费学习笔记（深入）”；
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
import "github.com/microcosm-cc/bluemonday"
policy := bluemonday.UGCPolicy() // 默认只放行常见富文本标签
cleaned := policy.Sanitize(userInput) // 返回纯字符串，无标签则为空
t.Execute(w, map[string]interface{}{
"SafeHTML": template.HTML(cleaned),
})
- 不要自己写正则删 script 标签——正则无法可靠解析 HTML，绕过方式太多
-
bluemonday.UGCPolicy()允许<p>、<strong>、<a href>（且自动限制协议为 http/https），但禁用onerror、javascript:等危险属性和协议 - 如果业务允许更宽松，可用
bluemonday.StrictPolicy()，但切勿用bluemonday.NilPolicy()—— 它等价于裸输出
为什么 text/template 和 html/template 不能混用？
两者底层解析逻辑不同：html/template 在编译阶段就识别上下文（URL、CSS、JS、HTML 标签内），并施加对应转义；text/template 没有上下文感知，一律按纯文本处理。
典型翻车现场：你在 html/template 里调用了一个返回 text/template 执行结果的函数，结果那个结果里的 <script> 没被转义，直接进了 HTML 流程。
- 错误示例：
{{template "sub" . | html}}中，如果"sub"是用text/template解析的，| html只是把它当字符串包一层template.HTML，不触发二次转义 - 正确做法：所有模板都统一用
html/template加载；子模板也必须是html/template实例，否则上下文链断裂 - 性能影响不大，但兼容性上，
html/template比text/template多一次上下文分析，对极简纯文本场景略重——不过 Web 渲染本来就是 HTML 场景，没必要省这点
HTTP header 和 template 输出顺序会影响 XSS 防御效果？
会，而且很隐蔽。如果你在执行 template.Execute 前没设置 Content-Type: text/html; charset=utf-8，某些旧版浏览器（尤其是 IE）可能触发 MIME sniffing，把响应当成纯文本或 JS 执行，绕过 HTML 转义的效果。
- 必须在
WriteHeader或第一次Write前设置：w.Header().Set("Content-Type", "text/html; charset=utf-8") - 注意：Go 的
http.ServeFile默认设了正确 header，但你自己用template渲染时不会自动设 - 另一个坑：
charset缺失或写成utf8（少横线）会导致部分浏览器 fallback 到 ISO-8859-1，而 UTF-8 编码的恶意 payload 可能被错误解释，触发编码混淆型 XSS
最麻烦的从来不是“怎么开开关”，而是“哪条路径漏掉了清洗”或者“哪个中间件悄悄改了 header”。上线前扫一遍所有 HTML 输出入口，确认三件事：模板类型统一、用户输入必经 sanitizer、header 设置在 render 之前。
