PHP防SQL注入唯一可靠方案是使用预处理语句；禁用拼接、废弃函数及字符串过滤，表名列名等结构需白名单校验，全链路一致执行方有效。
PHP 防 SQL 注入，核心就一条：绝不拼接用户输入到 SQL 字符串里。 用 mysqli 或 PDO 的预处理语句（prepared statement）是唯一靠谱的通用方案；其他所谓“过滤函数”或正则替换，要么漏掉边界场景，要么破坏数据本意，实际项目中不推荐单独使用。
为什么 mysql_real_escape_string() 不再安全？
这个函数早已被废弃（PHP 7.0 移除），且它只对单引号、反斜杠等做转义，无法覆盖所有上下文（比如数字型参数未加引号包裹时，攻击者可直接注入 1 OR 1=1）。更关键的是：它依赖当前连接的字符集设置，若连接未显式指定 utf8mb4，可能触发宽字节注入（如 %df%27 绕过）。
实操建议：
- 彻底删除所有对
mysql_*()函数的调用，它们已从 PHP 中移除 - 即使改用
mysqli_real_escape_string()，也仅限于调试或遗留系统临时补救，不能作为防御主力 - 字符串必须在引号内才有效——如果 SQL 是
WHERE id = ?（无引号），那任何字符串转义都无效
用 PDO::prepare() 正确绑定参数
预处理语句把 SQL 结构和数据完全分离，数据库驱动在底层确保参数只当值处理，不参与语法解析。这是目前最可靠、最易维护的方式。
示例（注意占位符类型与绑定方式）：
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $user, $pass);
$stmt = $pdo->prepare('SELECT * FROM users WHERE status = ? AND age > ?');
$stmt->bindValue(1, $_GET['status'], PDO::PARAM_STR); // 显式指定类型更稳妥
$stmt->bindValue(2, (int)$_GET['age'], PDO::PARAM_INT); // 数字强制转 int 再绑定
$stmt->execute();
常见错误：
- 用
exec()或query()直接执行拼接字符串，绕过了预处理机制 - 绑定时用
bindParam()却传入未初始化变量，导致空值或意外覆盖 - 在
LIKE查询中把通配符（%）拼进 SQL 字符串而不是参数值里，例如写成WHERE name LIKE '%?%'—— 这会报错，正确写法是WHERE name LIKE ?，然后绑定'%' . $_GET['q'] . '%'
哪些情况容易忽略预处理？
不是所有 SQL 都能用问号占位符。表名、列名、排序字段（ORDER BY）、UNION 分支数等属于“SQL 结构”，不能参数化。这时必须白名单校验：
- 排序字段只允许从固定数组中选取：
in_array($_GET['sort'], ['created_at', 'name', 'score'], true) - 表名映射为配置键：
$tables = ['user' => 'users', 'log' => 'admin_logs']; $table = $tables[$_GET['type']] ?? 'users'; - 动态
IN子句需按参数个数生成对应问号：$placeholders = str_repeat('?,', count($ids) - 1) . '?'; $sql = "WHERE id IN ($placeholders)";，再逐个绑定
别试图用 addcslashes() 或正则删掉所有非字母数字——用户昵称含 emoji、中文、连字符都是合理需求，过滤只会丢数据。
真正难的不是写对一个 prepare() 调用，而是整套代码里每个数据库交互点都保持一致：ORM 是否开启原生预处理、DB 类封装是否透传绑定逻辑、迁移脚本里有没有手写的 INSERT INTO ... VALUES (" . $_POST['x'] . ")。一个疏漏点就可能让整个防护形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
