PHP 连接 MySQL 的正确姿势：PDO 预处理为什么能防 SQL 注入

PDO 预处理之所以能防 SQL 注入，根本原因只有一个：它把「SQL 语句的结构」和「用户传入的数据」彻底分开了——先用占位符把语句模板发给数据库编译好，参数再通过独立通道单独传输，数据从头到尾不参与 SQL 解析，所以无论用户输入什么，都只能被当作「值」，永远变不成「代码」。

拼接字符串的写法，为什么一定会被注入

结论：只要用户输入参与拼接 SQL 字符串，注入就是时间问题，字符转义救不了你。

看这段最常见的错误写法：

$sql = "SELECT * FROM users WHERE email = '$email' AND status = 1";
$row = $pdo->query($sql)->fetch();

攻击者把 `$email` 填成 `' OR 1=1 -- `，拼接后语句变成 `WHERE email = '' OR 1=1 -- ' AND status = 1`，`--` 后面全部被注释掉，登录校验直接绕过。这类字符串在 MySQL 里称为「被解析成 SQL 语法的一部分」，危险就在这。

有人会说「我用 `mysqli_real_escape_string` 转义过」。转义能挡住大部分场景，但它依赖当前连接的字符集是否正确（历史上宽字节注入就出在这），而且一旦忘了转义某处、或者转义后又做了一次 `urldecode`，防线就破了。安全逻辑不该建立在「每次都记得转义」上。

PDO 的正确姿势：四条连接参数 + 占位符

结论：连接时关掉模拟预处理、开启异常模式，查询时一律用占位符传值，这是 PHP 访问 MySQL 的推荐基线。

$dsn = 'mysql:host=127.0.0.1;dbname=forum;charset=utf8mb4';
$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION, // 出错抛异常，别静默
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    PDO::ATTR_EMULATE_PREPARES   => false, // 关闭模拟预处理，走 MySQL 原生预处理
    PDO::ATTR_STRINGIFY_FETCHES  => false,
]);

`ATTR_EMULATE_PREPARES` 这一条尤其关键：PDO_MySQL 默认是开启模拟预处理的，此时 PDO 自己在前端做转义和字符串拼接，等于又回到了「靠转义吃饭」的老路。设为 `false` 后，语句模板发给 MySQL 编译，参数经二进制协议单独传输，注入面被彻底切断。`charset=utf8mb4` 写在 DSN 里也比事后 `SET NAMES` 更可靠。

查询写法：

$stmt = $pdo->prepare('SELECT id, username FROM users WHERE email = ? AND status = ?');
$stmt->execute([$email, 1]);
$user = $stmt->fetch();

命名占位符同样可用：`WHERE email = :email`，执行时传 `[':email' => $email]`，可读性更好，适合参数多的场景。顺便说一句，PHP 8.0 起错误模式默认已经是异常，但显式写出来更稳妥，老版本默认是静默失败，调试时会很痛苦。

占位符只能给「值」，这些位置必须走白名单

结论：占位符不能用在表名、列名、`ORDER BY`、`LIMIT` 等 SQL 结构位置上，这些地方只能用白名单映射。

这是最容易被误解的一点：`ORDER BY ?` 或 `FROM ?` 根本不会按你期望工作，因为它们是标识符/关键字，不是值。正确做法是白名单：

$allow = ['created_at', 'replies', 'views'];
$order = in_array($order, $allow, true) ? $order : 'created_at';
$sort  = $sort === 'asc' ? 'ASC' : 'DESC';
$limit = max(1, min(50, (int)$limit)); // 强转成整数，不可能是任意字符串
$sql = "SELECT id, title FROM posts ORDER BY {$order} {$sort} LIMIT {$limit}";

`IN` 列表则用占位符数量动态生成，元素先强转整数：

$ids = array_map('intval', $ids);
$in  = implode(',', array_fill(0, count($ids), '?'));
$stmt = $pdo->prepare("SELECT id, title FROM posts WHERE id IN ($in)");
$stmt->execute($ids);

三个高频踩坑

结论：同名命名占位符、LIKE 通配符、二次注入，是预处理用对了也会翻车的三个点。

第一，同名命名占位符在关闭模拟预处理后会报错。`WHERE a = :kw OR b = :kw` 在原生预处理下会抛 `HY093`，需要写成两个不同名字（`:kw1`、`:kw2`）。开启模拟时能跑，关掉后报错，很多人升级配置后才发现。

第二，`LIKE` 的通配符要处理。用户搜索词里带 `%` 或 `_` 会被当通配符，虽然不构成注入，但会拖慢查询、返回脏结果，建议对 `%`、`_`、`\` 做转义后再包上 `%...%`。

第三，二次注入不在预处理的保护范围内。数据用预处理安全存进库，之后又被取出直接拼进另一条 SQL，照样中招。防御靠的是「所有 SQL 一律走预处理」这个纪律，而不是某几处写了预处理。

预处理管不到的边界

结论：预处理只管「数据不被当代码执行」，XSS 输出转义、数据库账号最小权限、二次注入，都需要另外一层防线。

SQL 注入和 XSS 是两码事：PDO 帮你在入库时不炸数据库，但把用户昵称原样 `echo` 到页面照样是 XSS，输出必须做 HTML 转义。另外建议给应用配一个最小权限数据库账号，只授 `SELECT/INSERT/UPDATE/DELETE`，不给 `DROP`、`FILE`、`INTO OUTFILE`——这样即使某处漏了，攻击者也拿不到拖库或写文件的能力。

环境层面不用担心：以 Clara BBS 这类社区系统要求的 PHP 7.4–8.5 + MySQL 5.7+ 为例，PDO 及 pdo_mysql 扩展属于 PHP 自带且默认启用的组件，不需要额外安装，直接在代码里 `new PDO(...)` 就能用。

一句话收尾：把 `ATTR_EMULATE_PREPARES` 关掉、连接时 `charset=utf8mb4`、值一律走占位符、结构位置一律走白名单，这四条做到，SQL 注入这个坑基本就填平了；剩下的 XSS、越权、二次注入，是另外的账要另算。