thinkphp防xss核心是控输出而非拦输入；htmlspecialchars仅适用于html文本上下文，js、json、url等场景需分别用json_encode、urlencode等上下文敏感编码，富文本须用htmlpurifier白名单净化。
ThinkPHP 默认不自动过滤输出内容，直接 echo 变量到 HTML 页面极易触发 XSS —— 必须手动干预，且不能只靠一层防护。
为什么 htmlspecialchars 不够用？
它只适用于纯 HTML 文本上下文。但真实场景中，用户输入可能被插入到：<div> 内、<code><a href="..."></a> 属性里、<script></script> 标签中、甚至 JSON 响应体里。不同上下文需不同编码策略：
- HTML 元素内容：用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - HTML 属性值（尤其是双引号包围）：必须加
ENT_QUOTES，否则'逃逸仍可注入 - JavaScript 字符串内（如
var msg = "= $msg ?>";）：htmlspecialchars无效，应改用json_encode($msg, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG) - URL 参数值（如
<a href="?q=<?=%20%24q%20?>"></a>）：必须用urlencode($q)，而非htmlspecialchars
ThinkPHP 的 Response::filter() 怎么用才安全？
该方法仅对最终响应体做一次全局过滤，适合简单 CMS 类项目，但有明显局限：
- 它在输出前统一处理整个响应字符串，无法识别上下文 —— 比如把
<script></script>过滤掉，但若原始数据已含javascript:alert(1)在href中，仍会执行 - 默认配置不启用，需显式调用：
return response($content)->filter(true); - 底层实际调用的是
htmlspecialchars，不支持自定义白名单标签，无法保留富文本中的合法<img>或<strong></strong> - 若你用了
view渲染模板，Response::filter()对模板内的变量插值无影响，只作用于最终拼好的完整 HTML 字符串
需要富文本？别手写正则，用 HTMLPurifier
当业务允许用户发带格式的评论、文章摘要等，htmlspecialchars 会把所有标签干掉，这时必须引入专业净化库：
- 安装：
composer require ezyang/htmlpurifier - 配置要严格限定：
$cfg->set('HTML.Allowed', 'p,b,i,em,strong,a[href|title],img[src|alt|width|height]');—— 不开script、onerror、style（除非你同时配了CSS.AllowedProperties） - 务必设置
$cfg->set('Core.Encoding', 'UTF-8')，否则中文乱码+过滤失效 - 不要在控制器里每次 new 一个
HTMLPurifier实例，应封装为服务或静态工具，在模型保存前调用，避免重复净化
最容易被忽略的 XSS 入口：JSON 接口和 JS 模板
ThinkPHP 的 json() 方法默认不做任何转义，直接把数组转成 JSON 返回。如果其中字段含用户输入的 <script></script>，前端用 innerHTML 渲染就会执行：
- 错误写法：
return json(['msg' => $_POST['content']]); - 正确做法：前端接收后，用
textContent或innerText插入；或后端提前净化：'msg' => htmlspecialchars($_POST['content'], ENT_QUOTES, 'UTF-8') - 若用 Vue/React 渲染服务端返回的 JSON 数据，确保没用
v-html或dangerouslySetInnerHTML直接渲染未净化字段 - CSRF Token 若通过 JSON 返回并由 JS 注入到表单，也要确认该字段未被污染 —— 否则攻击者可伪造请求时注入脚本
真正防住 XSS 不是选一个函数，而是分清「哪里输」和「怎么输」：输入验证 + 上下文敏感编码 + CSP 头 + HttpOnly Cookie，四层缺一不可。尤其注意 ThinkPHP 的模板变量默认不转义（{$var}），{:$var} 才等价于 htmlspecialchars —— 这个细节，上线前常被漏掉。
