htmlspecialchars不能防范SQL注入，它仅转义HTML特殊字符以防止XSS，对数据库解析无影响；PDO预处理防注入必须关闭模拟模式（ATTR_EMULATE_PREPARES=false）并使用原生prepare/execute。
htmlspecialchars 不能防范 SQL 注入，和 PDO 预处理一起用时，它只负责 HTML 输出安全 —— 混用这两个函数会让人误以为“双重防护”，反而掩盖了根本没做 SQL 层防护的事实。
为什么 htmlspecialchars 对 SQL 注入完全无效
它只把 &、、<code>>、"、' 转成 HTML 实体，比如 <script></script> 变成 <script>。但数据库根本不解析 HTML 实体，它看到的仍是原始字符串。攻击者输入 admin' OR '1'='1，htmlspecialchars() 不动它分毫，拼进 SQL 后照样触发注入。
- SQL 注入发生在查询执行前，靠的是数据库引擎把用户输入当代码执行
-
htmlspecialchars()发生在 PHP 输出阶段，对 MySQL、PostgreSQL 等毫无影响 - 把它加在
$_POST输入上再传给PDO::prepare()，属于多此一举，还可能干扰正常数据（比如把用户昵称中的单引号转义后存进数据库）
PDO 防注入必须关闭模拟预处理
默认情况下，PDO 用的是模拟预处理（PDO::ATTR_EMULATE_PREPARES = true），也就是 PHP 自己做字符串替换，不发原生 PREPARE 到数据库 —— 这等于退化成拼接，完全失效。
- 初始化 PDO 时必须显式关闭：
PDO::ATTR_EMULATE_PREPARES => false - 检查是否生效：
var_dump($pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES));应返回bool(false) - MySQL 版本需 ≥ 5.1.17；若用 MariaDB，确认支持原生预处理（多数现代版本都支持）
- 如果因旧环境无法关掉模拟模式，就别用 PDO，改用
mysqli::prepare()+bind_param()，它默认走原生流程
正确分工：PDO 管 SQL 安全，htmlspecialchars 管输出安全
一个典型用户列表页，要同时防 SQL 注入和 XSS，两件事得分开做、各司其职：
立即学习“PHP免费学习笔记（深入）”；
- 查数据库用 PDO 预处理：
$stmt = $pdo->prepare("SELECT name, email FROM users WHERE status = ?"); $stmt->execute([$status]); - 往 HTML 里输出时才用
htmlspecialchars()：echo "<td>" . htmlspecialchars($row['email'], ENT_QUOTES, 'UTF-8') . "</td>"; - 如果输出到 JavaScript 字符串里，还得额外用
json_encode()：var email = <?php echo json_encode($row['email'], JSON_UNESCAPED_UNICODE); ?>; - 千万别写：
$safe_email = htmlspecialchars($_POST['email']); $stmt->execute([$safe_email]);—— 这既没增强 SQL 安全，又可能把用户合法输入（如 O’Connor）存成乱码
最常被忽略的一点：PDO 的安全性不依赖任何输入过滤函数，只依赖你是否真正用了 prepare() + execute()（且模拟关闭）。只要参数是作为数组或命名参数传进去的，中间不管有没有 trim()、filter_var() 或 htmlspecialchars()，都不影响 SQL 层防护效果 —— 它们解决的是别的问题。
