防止SQL注入的PHP使用PDO参数绑定与模拟预处理

防止SQL注入最有效的PHP手段就是使用PDO（PHP Data Objects）的参数绑定机制，配合模拟预处理（emulated prepares）来实现。简单来说，参数绑定就是把用户输入的数据和SQL语句的逻辑结构完全分开，数据库引擎在执行时不会把用户数据当作SQL指令来解析，从根本上杜绝了注入攻击的可能。而模拟预处理则是PDO的一种运行模式，它在PHP层面先对参数做转义处理，再把完整的SQL语句发给数据库执行，适合不支持真正预处理的老旧数据库驱动。

很多开发者到现在还在用mysql_query拼接字符串的方式写SQL，这是极其危险的。哪怕你做了addslashes、htmlspecialchars这些过滤，也挡不住所有攻击向量。PDO参数绑定才是业界公认的标准防御方案，下面我会从原理、写法、注意事项三个维度把这件事讲透。

SQL注入的本质是：攻击者把恶意SQL片段混入用户输入，让数据库把它当成正常指令执行。比如一个登录表单，用户名输入框里填了"admin' OR '1'='1"，如果你直接拼进SQL语句，就变成了永远为真的条件，攻击者不需要密码就能登录。

参数绑定的核心思路是"先有骨架，再填肉"。SQL语句在发送给数据库之前，已经是一个固定的模板，用户数据只是作为参数填进去，数据库引擎知道哪些是指令、哪些是数据，绝不会混淆。这就好比你填一张表格，表格格式是固定的，你只能在格子里写字，没法改表格本身的结构。

PDO提供了两种参数绑定方式：命名参数（:name）和位置参数（?）。命名参数可读性更好，位置参数写起来更快。两种方式的安全级别完全一样，都能防注入。

下面是最基础的PDO连接和参数绑定示例，涵盖了命名参数和位置参数两种写法：

// 建立PDO连接
$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$pdo = new PDO($dsn, 'username', 'password', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,  // 关闭模拟预处理，使用真正的预处理
]);

// 方式一：命名参数绑定
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email AND status = :status');
$stmt->execute([
    ':email' => $userInputEmail,
    ':status' => 1
]);
$user = $stmt->fetch(PDO::FETCH_ASSOC);

// 方式二：位置参数绑定
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = ? AND role = ?');
$stmt->execute([$userId, $userRole]);
$user = $stmt->fetch(PDO::FETCH_ASSOC);

注意看代码里的PDO::ATTR_EMULATE_PREPARES => false这一行。把它设为false，PDO就会使用数据库原生的预处理功能，也就是真正的prepared statement。设为true或者不设置（默认在某些驱动下是true），PDO就在PHP层面模拟预处理。

模拟预处理是PDO的一个兼容机制。当数据库驱动不支持真正的预处理语句时（比如某些老版本的MySQL驱动），PDO会在PHP内部把参数替换成转义后的值，拼成完整的SQL字符串，再发给数据库执行。从安全角度来说，模拟预处理也能防注入，因为PDO内部的转义逻辑是可靠的。

但模拟预处理有几个明显的缺点：第一，它不是真正的预处理，数据库看到的仍然是一条拼接好的完整SQL，无法利用数据库端的查询缓存优化；第二，在某些极端情况下，如果PDO内部转义逻辑有bug，可能存在风险；第三，它无法发挥数据库原生预处理的性能优势。

// 开启模拟预处理的写法（不推荐，但兼容老驱动时可用）
$pdo = new PDO($dsn, 'username', 'password', [
    PDO::ATTR_EMULATE_PREPARES => true,
]);

我的建议是：如果你的数据库驱动支持真正的预处理（MySQL 5.1+、PostgreSQL、SQLite等都支持），就把ATTR_EMULATE_PREPARES设为false。如果你必须兼容非常老的环境，设为true也比不用参数绑定强一万倍。

很多人以为用了参数绑定就万事大吉，其实还有几个坑必须避开。

第一个坑：动态表名和列名不能用参数绑定。参数绑定只能绑定值（value），不能绑定标识符（identifier）。如果你需要动态指定表名或列名，必须用白名单验证：

// 错误写法——这样不行
$table = $userInputTable;
$stmt = $pdo->prepare("SELECT * FROM :table");
$stmt->execute([':table' => $table]); // 报错或不生效

// 正确写法——白名单验证
$allowedTables = ['users', 'orders', 'products'];
$table = in_array($userInputTable, $allowedTables) ? $userInputTable : 'users';
$stmt = $pdo->prepare("SELECT * FROM {$table} WHERE id = ?");
$stmt->execute([$userId]);

第二个坑：IN查询的处理。如果你要做WHERE id IN (1,2,3)这种查询，不能直接绑一个数组，需要手动构造占位符：

$ids = [1, 2, 3, 5, 8];
$placeholders = implode(',', array_fill(0, count($ids), '?'));
$stmt = $pdo->prepare("SELECT * FROM users WHERE id IN ({$placeholders})");
$stmt->execute($ids);

第三个坑：LIKE模糊查询的通配符处理。如果用户输入包含%或_，直接绑定会被当成通配符匹配。正确做法是在绑定值里手动转义：

$search = $userInput;
$searchParam = '%' . str_replace(['%', '_'], ['\%', '\_'], $search) . '%';
$stmt = $pdo->prepare("SELECT * FROM products WHERE name LIKE ?");
$stmt->execute([$searchParam]);

第四个坑：事务中的参数绑定。在事务里使用参数绑定和普通查询没有区别，但要注意错误处理，事务回滚时要捕获异常：

try {
    $pdo->beginTransaction();
    
    $stmt = $pdo->prepare("UPDATE accounts SET balance = balance - ? WHERE id = ?");
    $stmt->execute([$amount, $fromId]);
    
    $stmt = $pdo->prepare("UPDATE accounts SET balance = balance + ? WHERE id = ?");
    $stmt->execute([$amount, $toId]);
    
    $pdo->commit();
} catch (Exception $e) {
    $pdo->rollBack();
    throw $e;
}

市面上防SQL注入的方法不少，我做一个横向对比，让你心里有数。

第一种：addslashes或mysqli_real_escape_string。这种方法是手动转义特殊字符，但它依赖字符集设置，如果字符集配置不对，照样能被绕过。而且代码里到处都是转义函数，维护成本高，容易遗漏。参数绑定从架构层面解决问题，不依赖字符集，不会遗漏。

第二种：过滤关键词，比如把SELECT、DROP、UNION这些词屏蔽掉。这种方法完全不靠谱，攻击者有无数种编码和变形方式绕过关键词过滤。参数绑定根本不需要关心用户输入了什么内容，因为数据和指令已经分离了。

第三种：ORM框架（如Laravel的Eloquent、ThinkPHP的模型层）。这些框架底层其实也是用参数绑定实现的，只是封装了一层。如果你直接用框架提供的查询构建器，安全性是有保障的。但如果你在框架里写原生SQL又不用参数绑定，那就等于白搭。

第四种：存储过程。存储过程本身也有参数化机制，可以防注入。但存储过程的可移植性差，调试困难，现代开发中用得越来越少。PDO参数绑定是更轻量、更通用的方案。

在真实项目中，我总结了几条必须遵守的规范：

第一，所有数据库操作统一使用PDO，不要混用mysqli或mysql扩展。混用会导致代码风格不一致，增加出错概率。

第二，永远不要信任用户输入。哪怕你用了参数绑定，也要在业务层做数据验证，比如邮箱格式、数字范围、字符串长度等。参数绑定防的是SQL注入，不是业务逻辑漏洞。

第三，开启PDO的异常模式（ERRMODE_EXCEPTION），这样SQL执行出错时会抛出异常，方便你捕获和处理，而不是默默失败或者暴露敏感信息。

第四，数据库账号权限要最小化。应用程序使用的数据库账号只给必要的权限，比如只给SELECT、INSERT、UPDATE、DELETE，不要给DROP、ALTER、CREATE这些高危权限。万一真的被注入了，攻击面也会小很多。

第五，定期更新PHP和数据库驱动版本。新版本会修复已知的安全漏洞，保持更新是基本的安全素养。

第六，对于复杂查询，考虑使用查询构建器或ORM，减少手写SQL的机会。手写SQL越多，出错的概率越大。但如果必须手写，参数绑定是底线。

回到最初的问题：防止SQL注入，用PDO参数绑定加模拟预处理（或者直接关闭模拟预处理用真正预处理）就是最硬核、最可靠的方案。它不是什么高深技术，而是PHP开发的基本功。任何一个严肃的PHP项目，都不应该出现字符串拼接SQL的代码。

模拟预处理作为兼容方案有它的存在价值，但在条件允许的情况下，优先使用真正的预处理。参数绑定本身不复杂，难的是养成习惯——每次写SQL都想到用绑定，而不是图省事直接拼字符串。把这个习惯刻进骨子里，你的代码安全性就能上一个大台阶。