htmlspecialchars 只在输出到 HTML 页面时有效，必须在 echo 或模板插值前调用；不能用于输入过滤或数据库入库；需显式指定 ENT_QUOTES 和 'UTF-8'；对 JS/CSS/URL 等上下文无效，须按场景选用 json_encode、urlencode 等方案。
htmlspecialchars 该在哪儿调用才真正起作用
它只对输出到 HTML 页面的内容有效，不是万能过滤器，也不是数据库入库前该干的事。很多人把它当“输入过滤”用，结果该漏的还是漏。
- 必须在
echo或模板变量插值前调用，比如echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8'); - 千万别在接收
$_GET或$_POST后立刻htmlspecialchars存进数据库——这会把单引号、双引号变成实体，导致搜索失效、JSON 解析失败 - 如果用了 Twig、Blade 等模板引擎，确认是否默认开启了自动转义（如 Twig 的
{{ }}默认转义，{% autoescape %}块也生效）
ENT_QUOTES 和 UTF-8 编码不匹配会出什么问题
常见现象是中文引号、单引号没被转义，或者页面出现乱码方块，本质是字符编码和 htmlspecialchars 的第三个参数没对齐。
- 确保 PHP 文件本身保存为 UTF-8（无 BOM），且响应头或
<meta>声明了charset=utf-8 - 第三个参数必须显式传
'UTF-8'，不能依赖默认值（PHP 5.4+ 默认是'UTF-8'，但老项目或某些 SAPI 下可能不一致） -
ENT_QUOTES要加上，否则单引号（'）不会被转成'，而 XSS 常用单引号闭合属性，比如<input value="<script>...</script>">
哪些地方 htmlspecialchars 根本不管用
它只处理 HTML 文本上下文，遇到 JS、CSS、URL、HTML 属性值等场景，直接套用会漏掉关键攻击面。
- 写入
<script></script>标签内？用json_encode($data, JSON_UNESCAPED_UNICODE)包一层再输出，别用htmlspecialchars - 拼在 URL 参数里？用
urlencode()，不是htmlspecialchars - 放在
style属性或内联 CSS 中？先过滤 CSS 关键字（如expression、javascript:），或改用外部样式表 + 类名控制 - 动态生成 HTML 标签名或属性名？
htmlspecialchars无效，应白名单校验（如只允许div、class、id）
为什么 addslashes 不能代替 htmlspecialchars
addslashes 是为 SQL 注入设计的，和 XSS 防护目标不同，混用反而制造假安全感。
立即学习“PHP免费学习笔记（深入）”；
-
addslashes只加反斜杠，不转义、<code>>、&，浏览器照样解析为标签 - 在双字节编码（如 GBK）下，
addslashes还可能触发宽字节注入，让转义失效 - 现代 PHP 应用该用 PDO 预处理防 SQL 注入，用
htmlspecialchars防 XSS，职责分开
最常被忽略的是上下文切换：同一段用户数据，可能同时出现在 HTML 正文、<script></script>、URL、CSS 里，每个位置都要单独做对应防护，没有“一次过滤，到处安全”这回事。
