必须用htmlpurifier白名单校验，strip_tags()和正则无效；其需显式配置html.allowed、禁用默认宽松模式，且仅适用于入库或渲染前一次性净化，不可重复处理。
服务端渲染前必须做 HTMLPurifier 白名单校验
直接用 strip_tags() 或正则删 <script></script> 是无效的。用户输入 <img src="x" onerror="alert(1)">、<div style="max-width:90%">、甚至注释包裹的脚本 <code><!--<script>--> 都能绕过。HTMLPurifier 是唯一经过长期 XSS 实战检验的方案，但它不是开箱即用：
• 必须显式配置 HTML.Allowed，例如 'p,strong,em,a[href|title],br,ul,ol,li'
• 禁用默认宽松模式，否则可能放行 onerror、javascript: 等危险属性
• 不适合高频调用（如每请求处理 10 段富文本），建议只在入库前或模板渲染前执行一次
• 切忌重复净化：存储时净化一次 + 渲染前再净化一次，容易把合法实体如 © 变成 ©
htmlspecialchars() 只适用于纯文本上下文，且参数不可省略
写 htmlspecialchars($input) 是危险的。它默认不转义单引号，攻击者在 title='{{ $input }}' 中填入 ' onclick=alert(1) 就能触发事件。
• 必须传三个参数：htmlspecialchars($input, ENT_QUOTES | ENT_HTML5, 'UTF-8')
• 仅限插入到 HTML 文本内容（<p>xxx</p>）、title 属性、<textarea></textarea> 的 value 等纯文本位置
• 绝对不能用于 href、src、onclick 等属性值——那里需要 filter_var($url, FILTER_VALIDATE_URL) + 协议白名单，或 json_encode() + JS 字符串转义
• 更不能把已转义过的字符串再喂给 htmlspecialchars()，会导致双重编码显示异常
网关层只做快速拒绝，不做内容清洗
Nginx / OpenResty / Kong 这类网关拦截，本质是「匹配 + 拒绝」，不是「过滤 + 放行」。
• 常见规则是用正则检查 $request_uri 和 $args，命中 <script></script>、javascript:、onerror= 等模式就直接返回 400 或 403
• 它不解析请求体，不修改 POST 数据，也不处理 DOM 层逻辑
• 所以 POST /render 提交一个含 <img onerror="fetch('/api/steal')"> 的 JSON body，网关大概率放行——这得靠后端应用层用 HTMLPurifier 处理
• 网关规则要尽量轻量，避免复杂正则拖慢吞吐；真正复杂的 HTML 解析和标签校验，必须下沉到业务代码里
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
前端提交时的 sanitize 只是辅助，不可信
在表单 submit 事件里跑 DOMPurify.sanitize()，只是为了预览友好，不是安全防线。
• 用户可绕过前端直接发请求，所以后端必须重新净化
• input 或 paste 事件监听无法覆盖拖放、语音输入、自动填充等路径
• 浏览器原生 textContent 赋值是安全的，但一旦用 innerHTML 插入未经净化的内容，XSS 立刻触发
• Vue 的 v-html、React 的 dangerouslySetInnerHTML 是明确的危险信号，使用前必须确保输入已通过 HTMLPurifier 或同等强度的白名单校验
最常被忽略的点是上下文错配：把只适用于文本内容的 htmlspecialchars() 用在 URL 属性里，或把 DOMPurify 结果直接拼进 onclick="doSomething('{{ html }}')" —— 这些地方既不是 HTML 上下文，也不是 JS 字符串上下文，而是混合上下文，必须分层处理。
