PHP 7.4 下不指定 ENT_QUOTES 和 'UTF-8' 极其危险，因其默认仅转义双引号（ENT_COMPAT），单引号保留，且默认编码非UTF-8，导致如 ' onclick="alert(1)" 可直接注入HTML属性触发XSS。
PHP 7.5 不存在，当前最新稳定版是 PHP 8.3（截至 2026 年 10 月），而 PHP 7.4 是最后一个 7.x 版本，仍被部分老项目使用——但它的 htmlspecialchars 行为与新版有关键差异，漏写参数极易触发 XSS。
为什么 PHP 7.4 下不写 ENT_QUOTES 和 'UTF-8' 就危险
PHP 7.4 默认 flags 是 ENT_COMPAT | ENT_HTML401，只转义双引号，单引号原样保留。若用户输入：' onclick="alert(1)"，直接塞进 HTML 属性：<input value="<?php echo $_GET['q']; ?>">，就会逃逸成可执行脚本。
同时，PHP 7.4 不自动推断编码：未传 encoding 参数时，它按 ISO-8859-1 处理，遇到 UTF-8 字节流可能截断多字节字符，造成「编码绕过」——比如 %C0%BC（非法 UTF-8）被解析为 后，后续的 ' 可能被当作独立引号解析。
- 必须显式写
htmlspecialchars($s, ENT_QUOTES | ENT_HTML5, 'UTF-8') - 别依赖
default_charset或mb_internal_encoding()，它们不影响htmlspecialchars - PHP 8.0+ 虽默认
UTF-8，但ENT_QUOTES仍需手动加，否则单引号照旧不转义
htmlspecialchars 放错位置：入库前调用是典型误用
常见错误是在接收 $_POST 后立刻对数据调用 htmlspecialchars，再存进数据库。结果是：数据库里存了 <script> 这种字符串，后续导出 CSV、生成 JSON API、做全文搜索时全乱套——json_encode() 会把已转义的 < 再包一层，前端拿到的是双重编码的垃圾。
立即学习“PHP免费学习笔记（深入）”；
-
htmlspecialchars只在输出到 HTML 上下文时调用，且仅一次 - 入库前该用参数化查询防 SQL 注入，不是用
htmlspecialchars - 如果模板引擎（如 Twig、Blade）启用自动转义，就别手写
htmlspecialchars，否则重复转义
HTML 属性值中 htmlspecialchars 的坑
在 value="..."、title='...' 这类属性里输出用户数据，光靠 htmlspecialchars 不够——你得确保属性本身被引号包裹，且引号类型和 flags 匹配。
例如：echo '<input value="' . htmlspecialchars($v, ENT_QUOTES, 'UTF-8') . '">'; 是安全的；但写成 echo "<input value=" . htmlspecialchars($v, ENT_COMPAT, 'UTF-8') . ">"; 就危险：单引号没被转，$v = "test' onfocus=alert(1)" 会直接突破。
- 统一用
ENT_QUOTES，不管属性用单引号还是双引号 - 避免无引号属性：
<input value="<?php" echo htmlspecialchars>>—— 空格、=、/都会导致解析失败或逃逸 - JavaScript 字符串内嵌用户数据？别用
htmlspecialchars，改用json_encode($v, JSON_HEX_TAG | JSON_HEX_AMP)
最易被忽略的一点：htmlspecialchars 不处理标签内部的事件属性（如 onerror）、style 中的 expression() 或 URL 协议（javascript:）。这类富文本场景必须用 HTMLPurifier 白名单过滤，而不是幻想靠 htmlspecialchars 一招鲜。
