能，但仅限于 html/template 且变量插值方式正确时；它默认对 {{.Name}} 等双大括号内容执行 HTML 实体转义（如 < → <），防止 XSS。
Go模板中自动转义能防XSS吗
能，但仅限于 html/template 且变量插值方式正确时。它默认对 {{.Name}} 这类双大括号中的内容执行 HTML 实体转义（如 → <code><），但前提是：必须用 html/template，不能混用 text/template；变量不能被显式标记为安全（如 {{.HTML | safeHTML}}）；也不能通过 template.HTML 类型绕过。
常见错误是把用户输入直接转成 template.HTML 后插入模板，这等于主动关闭防护：
func handler(w http.ResponseWriter, r *http.Request) {
name := r.URL.Query().Get("name")
// ❌ 危险：绕过所有转义
data := struct{ Name template.HTML }{template.HTML(name)}
t := template.Must(template.New("").Parse(`{{.Name}}`))
t.Execute(w, data)
}
哪些地方会绕过 html/template 的自动转义
以下情况会让 Go 模板完全不转义，必须人工校验或过滤：
-
{{.Name | safeHTML}}：显式声明内容“已安全”，模板跳过处理 -
template.JS、template.CSS、template.URL类型：对应上下文需不同转义规则，但模板只做最小化处理，不校验语法合法性 - 内联 JavaScript 中的
{{.JSVar}}：即使类型是template.JS，也无法阻止"); alert(1); //这类注入，因为 JS 解析器仍会执行 - HTML 属性值中使用未加引号的
{{.Attr}}：如<div data-id="{{.ID}}">，若 <code>.ID是1 onerror=alert(1)，会触发执行推荐的 XSS 防护组合策略
单靠模板转义不够，需分层拦截：
立即学习“go语言免费学习笔记（深入）”；
- 输入阶段：对 URL 查询参数、表单字段等，用
html.EscapeString()或正则限制（如只允许字母数字+下划线）做初步清洗，不依赖“后端存什么就显示什么” - 输出阶段：始终用
html/template，属性值一律加双引号：<input value="{{.Value}}">，避免无引号属性解析漏洞 - 富文本场景：禁用
template.HTML，改用专用库如bluemonday白名单过滤 HTML，再交给模板渲染 - HTTP 响应头加固：设置
X-Content-Type-Options: nosniff和X-XSS-Protection: 0（现代浏览器已弃用，但禁用可避免旧策略干扰），更关键的是Content-Security-Policy，例如default-src 'self'; script-src 'self'
为什么
bluemonday比手写正则更可靠手写正则很难覆盖所有 XSS 变种（如注释绕过、Unicode 编码、SVG 标签嵌套），而
bluemonday基于 HTML 解析器构建白名单，能准确识别标签、属性、URI 协议等上下文。比如它默认禁止onerror、javascript:、data:等危险模式，且支持细粒度配置：import "github.com/microcosm-cc/bluemonday" policy := bluemonday.UGCPolicy() policy.RequireNoFollowOnLinks(true) clean := policy.Sanitize(`<a href="https://www.php.cn/link/e8644ee27d873e0bb207499b0279b8e8">click</a>`) // → `<a rel="nofollow">click</a>`，危险 href 被移除
注意：
bluemonday不处理模板渲染逻辑，它只负责把原始 HTML 字符串变成安全 HTML 字符串，之后仍要传给html/template渲染，不能直接template.HTML(clean)插入——否则又绕过了一层。最易被忽略的是 CSP 策略的
script-src配置：如果用了'unsafe-inline'或宽泛的data:，前面所有防护都可能失效。 - 输入阶段：对 URL 查询参数、表单字段等，用
