最可靠的方式是使用预处理（Prepared Statements）。PDO预处理+参数绑定将SQL结构与数据完全分离，从根本上防止SQL注入；MySQLi预处理同样有效但写法更繁琐；而mysql_real_escape_string等转义方式已过时且存在多种漏洞。
PHP 查询语句防注入，最可靠的方式就是**不用拼接 SQL 字符串，改用预处理（Prepared Statements）**。其他所谓“过滤”“转义”“正则替换”都是补丁式做法，容易漏、难维护、不通用。
为什么 mysql_real_escape_string 不够用
这个函数只对单引号、反斜杠等做转义，但仅适用于 mysql_query 且必须配合单引号包裹变量——一旦漏写引号，或用于数字型字段未加引号，立刻失效。更严重的是：mysql_* 函数在 PHP 7.0+ 已被彻底移除，继续用等于主动放弃安全更新和语言支持。
- 它无法防御基于布尔/时间的盲注
- 对多字节编码（如 GBK）存在宽字节注入漏洞
- 不能保证类型安全：字符串转义后仍可能被当作数字参与运算
PDO 预处理 + 参数绑定是当前标准解法
PDO 的 prepare() 和 execute() 将 SQL 结构与数据完全分离，数据库驱动层负责把参数按类型安全地传入，根本不会解析成 SQL 代码。哪怕用户输入 ' OR 1=1 -- ，也只会当做一个普通字符串值处理。
$pdo = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = ? AND status = ?');
$stmt->execute([$_GET['id'], 'active']); // 自动识别类型，无需手动转义
$user = $stmt->fetch();
- 问号占位符（?）适合简单场景；命名参数（:name）更适合复杂查询，可重复使用
-
execute()接收数组时，所有值默认按字符串处理；如需指定类型，用bindValue()显式声明PDO::PARAM_INT或PDO::PARAM_BOOL - 确保 PDO 设置了
PDO::ATTR_EMULATE_PREPARES => false（默认 MySQL 驱动已启用真预处理）
MySQLi 同样支持预处理，但写法稍繁琐
MySQLi 面向对象风格也能做到同等防护，只是步骤更多：先 prepare()，再用 bind_param() 绑定变量类型和值，最后 execute()。类型字符串中 i（int）、s（string）、d（double）、b（blob）必须严格匹配，否则绑定失败或结果异常。
立即学习“PHP免费学习笔记（深入）”；
$mysqli = new mysqli('localhost', $user, $pass, 'test');
$stmt = $mysqli->prepare('SELECT name FROM products WHERE category = ? AND price > ?');
$stmt->bind_param('si', $_GET['cat'], $_GET['min_price']); // 注意类型顺序和变量引用
$stmt->execute();
$result = $stmt->get_result();
-
bind_param()的第一个参数是类型字符串，后续必须传变量（不是值），所以要提前定义好变量 - 如果参数来自数组或动态生成，PDO 的数组传参方式更灵活
- MySQLi 过程式写法（
mysqli_prepare()等）已基本被弃用，不建议新项目采用
真正麻烦的从来不是“怎么写预处理”，而是**如何让整个项目里所有 SQL 调用都走这一条路**——ORM、查询构建器、旧代码迁移、第三方库集成，都会带来例外情况。一旦某个角落用了 mysqli_query("SELECT * FROM t WHERE id = " . $_GET['id'])，整套防护就形同虚设。
