htmlspecialchars仅防XSS，不防SQL注入；其作用是将&、<、>、"、'转为HTML实体，确保输出到网页时安全，必须配合ENT_QUOTES和UTF-8参数使用，且只应在HTML输出环节调用。
htmlspecialchars 不是用来防SQL注入的
这是最常被误解的一点：htmlspecialchars 只负责转义 HTML 特殊字符（如 <、>、&），它对 SQL 查询中的引号、分号、括号等完全不处理。如果你把用户输入先过一遍 htmlspecialchars 再拼进 SQL 字符串，' OR 1=1 -- 这类 payload 依然能直接执行。
真正防 SQL 注入的只有参数化查询（PDO 或 MySQLi 的预处理语句）。htmlspecialchars 的作用是输出时防止 XSS，和数据库层完全不在一个环节。
参数化查询才是 SQL 安全的唯一可靠手段
所有用户输入必须通过绑定参数传入 SQL，而不是字符串拼接。PDO 是目前最推荐的方式：
$pdo = new PDO($dsn, $user, $pass);
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND status = ?");
$stmt->execute([$username, $status]); // 自动类型处理，无需手动转义
- 问号占位符（
?）或命名占位符（:name）由驱动底层处理，SQL 结构和数据彻底分离 - 即使
$username是"admin' -- "，也不会破坏语句结构 - 不要用
mysql_real_escape_string—— 已废弃且在多字节编码下有绕过风险 - 注意：PDO 默认开启
PDO::ATTR_EMULATE_PREPARES = true，某些旧版本会退化为模拟预处理，应显式关闭：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)
htmlspecialchars 只应在输出到 HTML 时使用
当从数据库读出数据并 echo 到网页时，才需要 htmlspecialchars：
立即学习“PHP免费学习笔记（深入）”；
// ✅ 正确：查询用参数化，输出用 htmlspecialchars
$stmt = $pdo->prepare("SELECT title, content FROM posts WHERE id = ?");
$stmt->execute([$id]);
$row = $stmt->fetch();
echo htmlspecialchars($row['title'], ENT_QUOTES, 'UTF-8');
- 必须指定
ENT_QUOTES和'UTF-8'，否则在 GBK 等编码下可能被绕过 - 不要在入库前调用
htmlspecialchars—— 数据库里存的是 HTML 转义后的字符串，后续做 JSON API、导出 Excel 或搜索时会出问题 - 如果模板引擎支持（如 Twig、Blade），优先用其自动转义机制，比手写
htmlspecialchars更可靠
常见组合误用场景和修复方式
比如用户提交表单后既要插入数据库，又要立刻在页面显示错误提示或成功信息：
- ❌ 错误做法：对
$_POST['name']先htmlspecialchars，再拼进 SQL - ✅ 正确做法：SQL 插入用
bindValue；渲染提示文字时再htmlspecialchars - ⚠️ 注意：如果用了
strip_tags或trim等过滤，也要放在参数绑定之后、输出之前，不能干扰参数化流程 - ⚠️ 多层嵌套时（如 JSON 返回给前端），
htmlspecialchars无意义，应确保前端框架自动转义或使用JSON.stringify输出
安全边界很清晰：数据库入口靠参数化，HTML 出口靠 htmlspecialchars。混用或错放位置，加固就变成假象。
