ThinkPHP防XSS关键在于分场景控制输出：普通文本依赖模板{$var}自动转义，富文本须白名单过滤后|raw输出；JSON、邮箱等场景需Unicode编码、域名白名单及CSP等纵深防御。
ThinkPHP 防 XSS 的关键不在“堵住所有输入”，而在于分场景控制输出：普通文本靠模板自动转义兜底，富文本则必须走白名单过滤 + 显式绕过转义。两者混用或错配，是老项目爆 XSS 的最常见原因。
模板变量默认已转义，但仅限 {$var} 语法
ThinkPHP（5/6/8）在模板编译阶段，会把 {$title} 自动编译为 echo htmlspecialchars($title, ENT_QUOTES, 'UTF-8');。这意味着：
- 只要用标准变量语法输出，无需手动调用 htmlspecialchars
- 转义强制使用 UTF-8 编码，不受
default_charset配置影响 - 该机制不作用于
{:$content}、{php}...{/php}或自定义函数调用 - 若变量本身已是 HTML 实体（如
<p>），会被二次转义成<p></p>，页面显示异常
富文本必须先净化，再用 |raw 输出
富文本内容（如文章正文、编辑器输出）天然含合法 HTML 标签，不能被自动转义。但直接 {$content|raw} 是高危操作——前提是内容必须已清洗。
- 入库前用 HTMLPurifier 做白名单过滤，只保留
p,br,strong,em,img,a等安全标签及属性（如a[href]限制协议为http/https） - 数据库字段类型设为
LONGTEXT，避免内容截断 - 模板中统一用
{$data.content|raw}输出，绝不用{:$data.content}（绕过变量检测与空值处理） - 切勿全局关闭
default_filter或禁用FilterValue中间件来“解决”富文本转义问题——这会让所有普通字段裸奔
警惕 JSON 接口和邮箱链接中的绕过点
前后端分离或邮件场景下，XSS 防御容易断档：
立即学习“PHP免费学习笔记（深入）”；
- API 返回 JSON 时，若前端用
innerHTML = data.content渲染，需对字符串做 Unicode 编码（如<→\u003c），防止浏览器解析执行 - 用户提交的外链 URL，
filter_var($url, FILTER_VALIDATE_URL)只验格式，不防钓鱼；必须提取parse_url($url, PHP_URL_HOST)并比对硬编码白名单域名 - 邮件模板中渲染用户链接，
htmlspecialchars()能防脚本，但无法阻止用户点击伪装域名，需结合短链跳转页做目标校验
补充纵深防御，不依赖单一环节
输出编码是核心，但不是全部：
- Cookie 设置
HttpOnly+Secure，阻断 JS 读取敏感凭证 - 响应头添加
Content-Security-Policy: default-src 'self'，限制脚本、样式、iframe 加载源 - 控制器中避免
echo $_GET['x']或print_r($userInput)等直出行为，哪怕只是调试 - 使用
allowField()和验证器$scene对 API 参数做字段级白名单，防止非法参数注入渲染逻辑
