htmlspecialchars() 防 XSS 必须显式传入 ENT_QUOTES | ENT_HTML5 和 'UTF-8' 编码，仅适用于 HTML 文本节点或属性值；输入过滤无效，JSON 输出需用 json_encode() 配合 HEX flags，模板引擎和 JS 拼接也需按上下文严格处理。
htmlspecialchars() 是输出时防 XSS 的第一道防线
直接在 HTML 上下文中输出用户数据，不转义就等于给攻击者开了后门。PHP 自带的 htmlspecialchars() 是最常用、最轻量、也最容易用错的函数。
关键不是“用了没”，而是“参数对不对”：
- 必须显式传入
ENT_QUOTES | ENT_HTML5，否则单引号不转义，<img src=x onerror=alert(1)>这类 payload 仍可触发 - 必须指定字符编码（如
'UTF-8'），否则 PHP 可能按 ISO-8859-1 解析，导致多字节截断绕过 - 只对输出到 HTML 文本节点或属性值有效；如果插进
<script>或onclick=里，它完全无效——那是上下文问题，不是转义问题
示例正确用法：
echo htmlspecialchars($user_input, ENT_QUOTES | ENT_HTML5, 'UTF-8');
不要用 strip_tags() 或正则过滤输入来防 XSS
输入过滤是典型误区。XSS 是输出上下文问题，不是输入“脏不脏”的问题。用户输入 <b>test</b> 完全合法，但你把它原样放进 <div onclick="..."> 就危险了。
立即学习“PHP免费学习笔记（深入）”；
strip_tags() 会被注释绕过（<!--<script>-->）、被自定义标签混淆（<svg onload=...>），而且删掉标签后语义可能错乱；正则更不可靠，HTML 解析器比任何正则都复杂。
- 输入该验证就验证（比如邮箱格式），该限制长度就限制，但别幻想“洗干净再存”就能一劳永逸
- 存储应保持原始（除非业务强要求富文本），渲染时按目标上下文决定怎么处理
- 如果真要支持有限 HTML（如后台编辑器），必须用专用库如
HTMLPurifier，而不是自己写规则
JSON 输出也要防，别忘了 json_encode() 的 flags
AJAX 接口返回 JSON，前端用 innerHTML 或 eval() 渲染？那 json_encode() 不加防护照样中招。默认它不会转义 HTML 实体，也不会阻止 Unicode 编码的 JS 执行。
- 服务端输出 JSON 前，确保用
json_encode($data, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT) - 更稳妥的是前端用
textContent而非innerHTML插入内容，服务端就不必为前端渲染方式兜底 - 如果接口被其他站点 JSONP 调用，还要加
Content-Type: application/json+ CORS 头，防止被 script 标签加载执行
模板引擎不是免死金牌，要看它怎么处理变量
Twig、Blade、Smarty 默认开启自动转义，但开发者一个 {{ var|raw }} 或 {!! $var !!} 就破功。这不是引擎的问题，是上下文误判。
- 确认模板里所有动态插入点是否都走转义路径；检查自定义过滤器、宏、include 是否悄悄 bypass 了安全机制
- JS 模板字符串里拼接 PHP 变量（如
`<div>${= json_encode($x) ?>}</div>`）必须用json_encode()，不能只用htmlspecialchars() - 内联样式或 URL 属性（
style="color: = $color ?>"）需要单独校验格式（如只允许 hex 或 named color），不能依赖通用转义
真正难的从来不是“有没有函数”，而是每次插入前，脑子里得过一遍：这段数据最终落在哪一层上下文里？HTML 文本？属性值？JS 字符串？CSS 值？URL？每个位置的安全要求都不一样。
