Gin防XSS核心是控制输出上下文与限制执行环境：必须用html/template自动转义HTML输出，JSON接口需设Content-Type和X-Content-Type-Options头，配合CSP响应头形成分层防护。
Gin 接口本身不渲染 HTML，所以不会直接触发 XSS；但如果你用 c.HTML 返回带用户输入的页面、或返回 JSON 后被前端不当 innerHTML 插入，XSS 就会发生。防范重点不在“拦截输入”，而在“控制输出上下文”和“限制执行环境”。
用 html/template 渲染 HTML 页面时必须启用自动转义
这是 Gin 中防 XSS 最低成本、最有效的手段。只要你不手动绕过，html/template 会把 {{.Name}}、{{.Content}} 这类变量自动转义为安全文本（如 <script></script> → <script></script>）。
- 必须用
html/template，不能用text/template—— 后者不转义任何内容 - Gin 的
c.HTML默认使用html/template，但你要确保传入的是原始字符串，而不是已拼好的 HTML 片段 - 如果业务需要插入可信富文本（如后台编辑的文章），必须显式调用
{{.SafeHTML | safeHTML}}，且该值必须经bluemonday等白名单库过滤后才可标记为 safe
返回 JSON 接口时也要防 XSS：别让前端误解析成 HTML
很多开发者以为“只返回 JSON 就安全”，但若响应头缺失或错误，浏览器可能 MIME 嗅探后当成 HTML 执行。攻击者诱导用户直接访问接口 URL，就能触发反射型 XSS。
- 务必设置
Content-Type: application/json; charset=utf-8，并在响应头中加X-Content-Type-Options: nosniff - 避免在 JSON 字段里塞完整 HTML 片段（如
{"msg": "），即使前端用"}
textContent显示，也可能被后续逻辑误用 - 对所有字符串字段做最小化校验：比如用户名只允许
[a-zA-Z0-9_]，评论内容长度限制 + 敏感词初筛（非黑名单，仅快速挡明显 payload）
配合 CSP 响应头堵住“万一漏掉”的执行路径
CSP 不是替代输入/输出防护，而是最后一道保险。它让即使有恶意脚本注入，也无法执行。
- 在 Gin 中统一加中间件设置关键头：
w.Header().Set("Content-Security-Policy", "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';") - 禁用
unsafe-inline和unsafe-eval—— 这两点是绝大多数 XSS 利用链的必要条件 - 不要依赖
X-XSS-Protection：现代浏览器已弃用，且mode=block在某些场景下反而导致功能异常
真正容易被忽略的点是：XSS 防护不是“某个函数一加就完事”，而是一整条链路的协同——输入校验只负责拦住明显非法字符，模板转义守住 HTML 输出，CSP 封死执行通道，三者缺一不可。尤其当你的接口既服务前端页面又提供 API 时，同一份用户数据可能走不同路径，必须按上下文分别设防。
