htmlspecialchars仅在html文本和带引号属性值中有效，对js、url、css、无引号属性及富文本等场景完全无效，须按上下文选用json_encode、urlencode、htmlpurifier等对应方案。
不够用，但它是关键一环——htmlspecialchars本身不是万能解药，而是特定场景下的精准工具。它只在“输出到HTML文本或带引号的属性值”这个上下文中真正起作用，用错地方或依赖它“一招鲜”，反而会留下严重漏洞。
它在哪管用：HTML文本和带引号的属性值
这是 htmlspecialchars 的舒适区：
- 输出在普通标签内容里，比如
<div><?php echo $name; ?></div>—— 此时用htmlspecialchars($name, ENT_QUOTES, 'UTF-8')能安全转义、<code>>、&、"、' - 输出在带引号包裹的属性中，比如
<input value="<?php echo $val; ?>">或<img alt="<?php echo $desc; ?>">—— 同样适用，前提是引号必须存在
漏掉 ENT_QUOTES 会导致单引号不被转义，攻击者就能闭合属性写入 onerror=alert(1)；不显式传 'UTF-8'，多字节编码下可能被截断绕过。
它在哪完全失效：JS、URL、CSS、无引号属性
这些地方硬套 htmlspecialchars 不仅无效，还制造虚假安全感：
-
写进
<script></script>标签内：比如var data = "<?php echo $user; ?>";—— 必须用json_encode($user, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)，否则或 Unicode 行分隔符（\u2028）会直接破局 -
拼在 URL 参数里：比如
<a href="search.php?q=<?php%20echo%20%24q;%20?>"></a>—— 应该用urlencode($q)，不是htmlspecialchars(urlencode($q)) -
放进 style 属性或内联 CSS：比如
<div style="color:<?php echo $color; ?>"> —— htmlspecialchars 不防 <code>expression()或javascript:，得过滤关键字或改用 class 控制 -
无引号的属性值：比如
<img src="x" onerror="alert(1)">—— 即使值被 htmlspecialchars 过，没引号照样触发 -
富文本内容：用户提交了
<img src="x" onerror="alert(1)">，你用 htmlspecialchars 处理后存库，前端再用innerHTML或dangerouslySetInnerHTML渲染 —— 浏览器看到的是已转义的字符串，不会执行，但也没达到“渲染为带格式的安全内容”的目标；更糟的是，如果后续逻辑又对这段内容做了解码或拼接，可能意外还原出可执行代码。这类场景必须交给HTMLPurifier白名单净化 -
入库前就 htmlspecialchars：把
$_POST['content']一接收就转义再存数据库 —— 单引号变'，搜索失效、JSON 字段解析失败、导出 Excel 出乱码，纯属自找麻烦。XSS 是输出问题，不是存储问题 - HTML 文本/属性 →
htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8') - JS 字符串变量 →
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_QUOT) - URL 查询参数 →
urlencode($param) - 富文本 →
HTMLPurifier配置白名单（如只允许<p><strong><img src></strong></p>，且限制src协议、禁掉onerror等事件属性） - 纯文本字段（用户名、标题等）→ 可先
strip_tags()再htmlspecialchars()，但别指望strip_tags()能保富文本安全
它不能碰的两类内容：富文本和输入过滤
这两个常见误用，是 XSS 漏洞高发区：
真正够用的组合策略
靠一个函数防不住 XSS，要按上下文切换工具：
模板引擎如 Twig、Blade 默认开启自动转义，也要确认是否覆盖所有变量插值点，尤其注意 {!! !!}、{{{ }}} 这类非转义语法。
