html/template 自动转义能防 XSS，但只在正确使用时生效：必须用 html/template、通过 {{.Field}} 插入、不手动绕过转义；富文本需 bluemonday 过滤后才可转 template.HTML；CSP 是最后一道防线，须设响应头且配合 Content-Type 与 X-Content-Type-Options。
html/template 自动转义能防 XSS，但只在正确使用时生效
Go 的 html/template 是防 XSS 最有效、最轻量的机制——它不是“可选防护”，而是默认行为。只要满足三个条件：用的是 html/template（不是 text/template）、变量通过 {{.Field}} 插入、没手动绕过转义，恶意字符串如 就会变成纯文本显示，不会执行。
- 常见错误：把用户输入强转为
template.HTML后直接传入模板，等于主动关掉防护 - 常见错误：在 Go 代码里拼接 HTML 字符串（比如
"），再塞进" + userInput + ""text/template，完全跳过转义逻辑 - 注意上下文：在 JS 字符串里插值（如
var name = "{{.Name}}";）仍由html/template自动做 JS 上下文转义，但若写成var name = {{.Name}};（不加引号），就可能触发语法错误或绕过
富文本场景必须用 bluemonday 过滤，不能靠 template.HTML 伪装安全
博客、评论区允许带格式内容？那不能简单禁用转义，而要引入白名单过滤。bluemonday 是 Go 生态最成熟的 HTML 消毒库，它按规则清理标签和属性（比如保留 、，但删掉 onerror=、、javascript: 等所有危险模式）。
立即学习“go语言免费学习笔记（深入）”；
- 过滤后的内容才可转为
template.HTML并用{{.SafeHTML}}渲染；未过滤前绝不可信 - 不要自己写正则去“删 script 标签”——正则无法处理嵌套、注释、编码绕过等变体，极易被 bypass
- bluemonday 默认策略较保守，可根据业务调整白名单，但
iframe、object、事件属性（onclick等）建议始终禁用
Content-Security-Policy 是最后一道防线，不是可有可无的装饰头
CSP 不是用来替代转义的，而是当某处漏掉防护、或 DOM 型 XSS 触发时，阻止脚本加载或执行。一个基础但有效的策略是：default-src 'self'; script-src 'self'。这意味着浏览器只允许加载同源脚本，连内联 和 eval() 都会被禁止。
- 务必配合
http.Header().Set("Content-Security-Policy", ...)设置响应头，不能只靠 meta 标签（meta 不适用于 worker、fetch 等场景） - 开发阶段可先用
Content-Security-Policy-Report-Only收集违规日志，避免误伤正常功能 - 如果用了 CDN 或字体服务，需显式添加域名到
script-src或font-src，否则资源会加载失败
别忽略 JSON 接口和 HTTP 头的细节
API 返回 JSON 时，XSS 风险依然存在——比如浏览器误将 text/plain 当作 HTML 解析，或攻击者诱导用户下载并双击打开响应体。所以必须设置两个头：Content-Type: application/json; charset=utf-8 和 X-Content-Type-Options: nosniff。
- 前者声明真实类型，后者禁止 MIME 嗅探，两者缺一不可
- 别忘了
X-XSS-Protection: 1; mode=block（虽现代浏览器已逐步弃用，但对旧版 IE/Edge 仍有意义） - 所有响应都应设
X-Frame-Options: DENY，防止被嵌入 iframe 实施点击劫持
真正容易被忽略的，是「信任边界」的模糊——比如认为“后台管理员发的内容一定安全”，结果管理员账号被钓鱼，富文本过滤规则又被降级，漏洞就从一个点扩散成全线失守。XSS 防护不是某个函数调用，而是每次输出前的一次确认：这数据来自哪里？谁控制它？它会在什么上下文中被解释？
