PHP PDO 禁用模拟预处理后的参数类型边界

PHP PDO 设置 PDO::ATTR_EMULATE_PREPARES 为 false 后，变化是“预处理交给驱动和数据库的原生能力”，不是“所有输入自动获得正确的数据库类型”。工程上最稳的边界是：连接配置负责选择原生预处理，bindValue() 负责表达参数类型，业务校验负责判断值是否合法。

官方手册：https://www.php.net/manual/en/pdo.prepare.php

把“禁用模拟预处理”当成模式边界

PDO 的模拟预处理由 PHP 侧改写 SQL 并处理参数；禁用模拟预处理后，PDO 会尝试使用驱动提供的原生 prepared statement。这个切换有明确的适用压力：希望 SQL 模板与参数分开交给驱动，减少应用层对 SQL 文本解析和转义的依赖。

但它并不替应用决定“这个输入应该是整数还是字符串”。同一个 PHP 变量可以来自查询字符串、JSON 或命令行参数，业务上是数字，运行时却可能仍然是字符串。原生预处理解决的是语句与数据的传递边界，业务类型仍由调用方负责。

典型实现：连接、类型和校验各自负责一件事

把连接属性集中配置，再在语句边界显式绑定类型，代码的职责会比较稳定。下面的例子用分页查询说明一个常见组合：状态是字符串，偏移量和页大小是整数。

 false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

// 业务校验先限制范围，避免把类型绑定误当成分页参数校验。
$state = trim((string) $input['state']);
$offset = filter_var($input['offset'], FILTER_VALIDATE_INT);
$pageSize = filter_var($input['page_size'], FILTER_VALIDATE_INT);
if ($offset === false || $offset  100) {
    throw new InvalidArgumentException('分页参数不合法');
}

$stmt = $pdo->prepare(
    'SELECT id, title FROM posts
     WHERE state = :state
     ORDER BY id DESC
     LIMIT :offset, :page_size'
);
// 字符串和整数是不同的数据角色，绑定时不要依赖默认类型。
$stmt->bindValue(':state', $state, PDO::PARAM_STR);
$stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
$stmt->bindValue(':page_size', $pageSize, PDO::PARAM_INT);

// execute 只负责执行已经准备好的语句，结果交给调用方继续处理。
$stmt->execute();
$posts = $stmt->fetchAll(PDO::FETCH_ASSOC);
?>

这段代码的关键不是把所有值都强行转成整数，而是让每个参数的业务角色可读：state 是文本，offset 与 page_size 是经过范围校验的分页整数。若驱动或数据库对某个 SQL 结构有特殊限制，应以对应驱动手册为准，不要把模拟预处理和原生预处理的行为想象成完全相同。

用 bindValue 把数据角色写清楚

PDOStatement::bindValue() 接收参数名或位置、值和类型。官方常量中，PDO::PARAM_STR 表示字符串，PDO::PARAM_INT 表示整数，另外还有布尔值与 SQL NULL 等类型。类型参数描述的是传给驱动的参数形态，不是“这个值已经通过了业务验证”。

当参数是可选值时，NULL 也应明确表达；当参数是开关时，是否接受字符串 "0"、"1" 应由业务层先转换，而不是直接把任意输入交给 PDO::PARAM_BOOL：

prepare(
    'UPDATE jobs SET enabled = :enabled, expires_at = :expires_at WHERE id = :id'
);
$stmt->bindValue(':enabled', $enabled, PDO::PARAM_BOOL);
$stmt->bindValue(':expires_at', $expiresAt, $expiresAt === null ? PDO::PARAM_NULL : PDO::PARAM_STR);
$stmt->bindValue(':id', $jobId, PDO::PARAM_INT);

// 类型绑定完成后再执行，避免在绑定后临时修改变量造成误解。
$stmt->execute();
?>

反例：把 execute 数组、类型绑定和校验混成一层

为了少写几行，有人会把所有参数直接放进 execute()。这种写法不是永远错误，但它隐藏了一个重要事实：仅使用参数数组时，调用者没有在每个参数旁边表达 PDO::PARAM_INT、PDO::PARAM_BOOL 或 PDO::PARAM_NULL。对于页码、金额、状态开关等边界敏感值，省略这层信息会让行为依赖驱动和数据库的类型转换。

prepare('SELECT * FROM posts WHERE id = :id AND state = :state');
$stmt->execute([
    ':id' => $input['id'],
    ':state' => $input['state'],
]);
?>

更容易审查的写法是：需要显式类型的参数用 bindValue()，简单的纯字符串条件才考虑参数数组；无论采用哪种写法，格式校验、范围校验和业务白名单都不能省略。尤其不要因为设置了 PDO::PARAM_INT，就认为字符串 "12abc" 已经被拒绝；类型绑定不是验证器。

反例：试图用占位符绑定表名、列名或 IN 列表

参数标记代表的是一个完整的数据字面量。它不能替换表名、列名、排序关键字，也不能把一个数组自动展开成 IN (?, ?, ?)。这不是把模拟预处理关闭后才出现的限制，而是参数占位符的职责边界。

prepare('SELECT * FROM :table WHERE id = :id');

// 正确方向：结构选项先做固定白名单映射，数据值继续使用占位符。
$tableMap = [
    'posts' => 'posts',
    'archived_posts' => 'archived_posts',
];
$tableName = $tableMap[$input['table']] ?? null;
if ($tableName === null) {
    throw new InvalidArgumentException('不支持的表名');
}

$stmt = $pdo->prepare("SELECT * FROM {$tableName} WHERE id = :id");
$stmt->bindValue(':id', $id, PDO::PARAM_INT);
$stmt->execute();
?>

同理，动态排序只能从固定的列名和方向映射中选择；动态 IN 条件则应按元素数量生成独立占位符，再逐个绑定。不要把“参数化”理解为任意 SQL 片段的通用拼接器。

架构判断清单：什么时候该显式绑定类型

可以把这套模式压缩成一次代码审查：连接层只决定是否使用原生预处理，查询层只描述占位符，业务层负责把外部输入收敛为合法值，绑定层负责把值的数据库角色写清楚。

• 这个参数是完整的数据值，还是 SQL 结构的一部分？
• 外部输入是否已经做了格式、范围或白名单校验？
• 是否需要在 bindValue() 处明确 PDO::PARAM_*？
• 同一条语句换到目标驱动后，原生预处理是否仍支持该占位符位置？
• 代码是否把类型绑定、输入验证和权限判断混成了一个“安全开关”？

常见问题

设置 ATTR_EMULATE_PREPARES=false 后，所有参数都会按数据库类型传递吗？

不会。它选择驱动的原生预处理路径；参数具体以什么类型绑定，仍取决于调用时传入的绑定类型和驱动行为。

execute 参数数组能不能完全替代 bindValue？

简单字符串条件可以使用参数数组，但对整数、布尔值、NULL 或驱动敏感的边界参数，显式使用 bindValue 更容易表达意图和审查。

PDO::PARAM_INT 能拦截非数字字符串吗？

不能把它当作输入校验器。先用业务层的格式和范围规则判断输入，再用 PARAM_INT 表达已确认的整数角色。

为什么表名不能写成一个占位符？

占位符代表数据值，而表名和列名属于 SQL 结构。结构选项应使用固定白名单映射，数据条件继续用占位符绑定。