mysqli_real_escape_string 仅对单引号包裹的字符串有效，无法防护数字上下文、标识符注入及宽字节漏洞；预处理语句（PDO::prepare + bindValue）通过SQL与数据分离实现根本防护。
mysqli_real_escape_string 为什么不能单独防 SQL 注入
它只是把引号、反斜杠这些字符加个转义，但前提是：你得在单引号包裹的字符串里用它，而且必须配合 mysqli 连接句柄。如果直接拼进 SQL 里又没加引号，比如 WHERE id = $id，那 mysqli_real_escape_string 压根不生效——数字上下文根本不管转义。
- 只对字符串值有效，对数字、标识符（如表名、字段名）完全无效
- 必须传入有效的
mysqli实例，NULL或关闭的连接会警告甚至失败 - 如果数据库连接字符集没设对（比如 PHP 用
utf8mb4，但连接没执行SET NAMES utf8mb4），可能绕过转义（宽字节注入） - 示例错误写法：
$sql = "SELECT * FROM user WHERE id = " . mysqli_real_escape_string($conn, $_GET['id']);—— 这里$_GET['id']是数字，不加引号，转义白做
PDO::prepare + bindParam 才是正解
预处理语句把 SQL 结构和数据彻底分离，数据库引擎先编译 SQL 模板，再把参数当纯数据塞进去——无论你传的是 ' OR 1=1 -- ' 还是 0xdeadbeef，它都不会被当 SQL 执行。
- 必须用
?占位符或命名参数（如:name），不能把变量拼进 SQL 字符串里 -
bindParam和bindValue区别在于：前者传引用，适合循环复用；后者传值，更安全直观，推荐新手用bindValue - 注意类型指定：
bindValue(':id', $_GET['id'], PDO::PARAM_INT)比默认PDO::PARAM_STR更严谨，尤其对数字字段 - 示例正确写法：
$stmt = $pdo->prepare("SELECT * FROM user WHERE name = :name"); $stmt->bindValue(':name', $_GET['name'], PDO::PARAM_STR); $stmt->execute();
过滤输入 ≠ 防注入，htmlspecialchars 不解决 SQL 问题
htmlspecialchars 是为 HTML 输出服务的，把 变成 <code>，防止 XSS。它对 SQL 查询毫无作用——数据库根本不关心你输出时有没有转义 HTML 实体。
- 常见误操作：对用户输入先
htmlspecialchars再拼 SQL，以为“双重保险”，实际等于没防 - 更危险的是：如果之后还要把这串数据再显示到页面，又套一层
htmlspecialchars，可能造成双重编码（如<） - 记住原则：SQL 防注入只发生在**查询构造阶段**，和后续怎么显示、怎么日志、怎么缓存都无关
还有哪些地方容易漏掉？
预处理不是万能银弹，有些场景它压根用不了，这时候得换思路。
立即学习“PHP免费学习笔记（深入）”；
- 表名、字段名、ORDER BY 字段不能用占位符——
SELECT * FROM ?语法错误。必须白名单校验：in_array($_GET['sort'], ['created_at', 'name']) - UNION 查询的列数、类型要一致，但攻击者可能用
UNION SELECT NULL,NULL,user(),NULL猜字段，所以后端要严格限制可选的UNION模式，别让用户自由填 SQL 片段 - ORM（如 Laravel Eloquent）默认用预处理，但调用
whereRaw或DB::statement时，又回到手拼 SQL 的风险区，得人工核对是否用了绑定 - 配置文件、环境变量里如果硬编码了 SQL 片段（比如某些老 CMS 的插件配置），也得当心——这些地方没人帮你做预处理
真正麻烦的从来不是“会不会用 prepare”，而是那些没法用 prepare 的边界情况，以及团队里有人偷偷写了 mysql_query("SELECT * FROM $table") 却没被 Code Review 发现。
