ThinkPHP 不提供入库自动转义防存储型 XSS，因XSS风险在输出环节而非入库环节；应原样存储、按上下文输出编码，富文本需用 HTMLPurifier 输出前清洗。
ThinkPHP 本身不提供“入库自动转义”来防 XSS 存储型攻击——这是常见误解。XSS 存储型攻击的根源在「输出环节」，而非入库环节。把用户输入 htmlspecialchars() 后存进数据库，反而会导致页面显示一堆 HTML 实体（比如 <script>），既破坏富文本内容，又没真正解决问题。
为什么不能靠入库转义防存储型 XSS
存储型 XSS 的触发点是：恶意脚本被存入数据库 → 后续被读出、未经处理直接输出到 HTML 页面 → 浏览器执行。关键风险不在「存」，而在「取出来怎么用」。
- 入库时提前
htmlspecialchars()，等于把原始内容污染了，后续想安全渲染富文本（如后台编辑器内容）就完全不可逆 - 同一段数据可能输出到多个上下文：HTML 正文、
textarea的 value、data-*属性、JS 变量、URL 参数……入库时统一转义无法适配所有场景 - ThinkPHP 的
Db::insert()或模型save()默认不做任何 HTML 转义，这是正确设计——数据库只管存原始语义，不该越权处理展示逻辑
正确的防御链条：入库原样存，输出按上下文转义
必须严格区分「输入校验」「存储格式」「输出编码」三个阶段：
- 入库前可做基础过滤（如
strip_tags($input, '<p><br><strong>')
白名单保留标签），但不要做htmlspecialchars() - 数据库字段类型建议用
TEXT（非HTML-escaped TEXT），保持内容原始性 - 输出到 HTML 模板时，优先依赖 ThinkPHP 模板引擎默认行为：
{$content}自动调用htmlspecialchars()；若关闭了默认转义（如用了{$content|raw}），就必须手动补：{$content|htmlspecialchars} - 输出到 JS 变量时，不能用
htmlspecialchars()，而要用json_encode($content, JSON_UNESCAPED_UNICODE)包裹后 echo，再在 JS 中安全使用
富文本场景必须用 HTMLPurifier 过滤输出
当业务需要支持 <img>、<a> 等安全标签（如后台富文本编辑器），htmlspecialchars() 会把所有标签干掉，此时必须在输出前清洗 HTML，而不是入库前转义：
立即学习“PHP免费学习笔记（深入）”；
- 安装：
composer require ezyang/htmlpurifier - 在
app/common.php定义清洗函数：function purify_html($html) { /* 配置允许的标签和属性 */ return (new \HTMLPurifier($config))->purify($html); } - 模板中使用：
{:purify_html($article->content)}，确保只放行白名单内的 HTML 结构 - 切勿在入库时调用该函数——它本就是为「输出前最后一道清洗」设计的
容易被忽略的坑：AJAX 返回 JSON 里的 XSS
ThinkPHP 的 json() 响应方法默认不转义字符串字段，如果接口返回的 data.title 是用户可控内容，前端用 innerHTML 直接插入，照样触发 XSS：
- 后端返回前，对每个字符串字段做
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')不可行（JSON 格式会被破坏） - 正确做法是：前端接收 JSON 后，用
textContent插入纯文本，或用DOMPurify.sanitize()处理 HTML 字段 - 后端可加一层保障：对明确含 HTML 的字段（如
content_html），在 API 层调用purify_html()再塞进 JSON，而非依赖前端
最危险的操作，是以为“入库时 htmlspecialchars 一下就安全了”，结果既毁了数据可用性，又漏掉了真正的输出点。XSS 防御成败，永远取决于你最后一次把数据扔给浏览器之前，有没有做对上下文匹配的编码。
