PHP PDO 怎样让预处理语句保留原生参数类型

PHP PDO 想让预处理参数保持明确的类型意图，不能只设置 PDO::ATTR_EMULATE_PREPARES 为 false。以 PDO_MYSQL 为例，应优先请求原生预处理，再用 bindValue 或 bindParam 显式指定 PARAM_INT、PARAM_STR、PARAM_NULL 等绑定类型，最后无参数调用 execute。PHP 变量类型、PDO 绑定类型、数据库表达式类型和查询结果类型是不同层次。

官方文档：https://www.php.net/manual/en/book.pdo.php。本文只讨论 PHP 8.x 与 PDO_MYSQL 的常见写法；示例表与连接由读者环境提供，未运行 SQL，也没有声称所有驱动都具有相同的类型行为。

先把原生预处理和参数绑定类型分开

我在选择这类写法时，更在意代码能否表达字段语义，而不是给所有参数统一加一个类型转换。分页大小是整数，带前导零的订单号却是字符串；如果只看它们“能不能转成数字”，反而容易把业务含义改掉。这是设计取舍，不是一次虚构的线上排障经历。

原生预处理讨论的是 SQL 在哪里准备、怎样交给驱动与服务器；绑定类型讨论的是参数值按什么类型传入。关闭模拟不代表 execute 数组会自动根据每个 PHP 值推断出开发者期望的绑定类型。PHP 官方 execute 手册把这种数组传参说明为按 PARAM_STR 处理。

所以我会把最小配方固定成：连接时明确模拟配置，先验证输入，再显式绑定，最后 execute()。驱动可能存在原生准备不适用而回退的情况，不能把一个连接属性当作每条 SQL 都必定通过服务端原生准备的证明。

用 bindValue 明确绑定分页整数

以下示例假设 articles 有 id、title、tenant_id 字段，使用固定查询和独立占位符。APP_DB_DSN 应由部署系统提供 MySQL DSN，例如按环境设置字符集；凭据不写入文章示例或日志。

 PDO::ERRMODE_EXCEPTION,
    // 本例限定 PDO_MYSQL，优先请求原生预处理
    PDO::ATTR_EMULATE_PREPARES => false,
]);

// 业务输入先校验，不能依赖 PARAM_INT 拒绝错误字符串
$rawLimit = '25';
$limit = filter_var($rawLimit, FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 100],
]);
if ($limit === false) {
    throw new InvalidArgumentException('分页大小必须为 1 到 100 的整数');
}
$tenantId = 12;
$offset = 0;
$stmt = $pdo->prepare(
    'SELECT id, title FROM articles
     WHERE tenant_id = :tenant_id ORDER BY id LIMIT :limit OFFSET :offset'
);
try {
    // 整数值与 PDO 绑定类型同时明确
    $stmt->bindValue(':tenant_id', $tenantId, PDO::PARAM_INT);
    $stmt->bindValue(':limit', $limit, PDO::PARAM_INT);
    $stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
    // 不再传参数数组，沿用上面设置的绑定
    $stmt->execute();
    $rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
} finally {
    // 即使消费结果发生异常，也释放当前语句游标
    $stmt->closeCursor();
}

这里 rawLimit 虽然来自字符串形式，先经过整数范围检查，才以 PARAM_INT 绑定。直接把任意输入强转成 int 可能掩盖非法内容；绑定常量不是通用输入校验器。tenantId 在例子里是固定整数，真实系统应从已授权的业务上下文取得，参数化也不能替代租户权限检查。

参数绑定以后，不要又调用 execute(['limit' => $limit, ...]) 来覆盖同一轮的参数来源。选择数组路径或显式绑定路径应保持清晰；本例选择后者。LIMIT 和 OFFSET 的整数要求正好能说明为什么“字符串看起来是数字”与“明确按整数绑定”值得区分。

异常模式让 prepare 或 execute 的错误可以交给上层统一处理；不要把带连接细节的原始异常直接回显给用户。finally 中的 closeCursor 用于释放语句结果资源，不是关闭整个数据库连接。

字符串、空值与循环参数各自处理

最小配方要按字段调整，而不是把所有参数都绑定成整数。订单号 000482 的前导零有业务意义；NULL 则不是空字符串，也不是文字“NULL”。下面两段复用已经建立的连接：

// 订单号含前导零，应保持字符串语义
$stmt = $pdo->prepare('SELECT id FROM orders WHERE order_code = :code');
$stmt->bindValue(':code', '000482', PDO::PARAM_STR);
$stmt->execute();
try {
    $row = $stmt->fetch(PDO::FETCH_ASSOC);
} finally {
    $stmt->closeCursor();
}

// SQL NULL 使用明确的绑定类型；表达式本身也要符合 NULL 语义
$nullStmt = $pdo->prepare('SELECT :value IS NULL AS is_null');
$nullStmt->bindValue(':value', null, PDO::PARAM_NULL);
$nullStmt->execute();
try {
    $nullRow = $nullStmt->fetch(PDO::FETCH_ASSOC);
} finally {
    $nullStmt->closeCursor();
}

第二段使用 IS NULL，是因为 SQL 中“等于 NULL”与判断为空不同。实际可空过滤条件要在查询设计时明确，不能只把绑定类型改成 PARAM_NULL，却仍期待普通等号匹配空值。

循环执行时，我倾向于用 bindValue 在每轮显式绑定新值，便于看清这一轮取了什么。bindParam 则绑定变量引用，在执行时读取变量，适合确实需要复用变量的场景；它不能直接接收任意临时表达式作为引用参数。选择时先考虑生命周期和可读性，不必为了复用预处理对象把所有写法改成引用。

超出 PHP 整数范围的编号不要先转成 int；精确金额也不应仅为绑定方便先转成浮点。PDO 没有一个对所有驱动都通用的“精确小数原生常量”，应结合数据库列和业务契约处理。数据库仍可能按列定义与表达式进行转换，不能承诺 PHP 原始类型在 SQL 全程逐位不变。

结果类型不能用输入绑定来保证

输入的 PARAM_INT 不保证 SELECT 返回的每一列都是 PHP int。结果还受驱动、客户端库、数据库列与表达式以及结果属性影响。ATTR_STRINGIFY_FETCHES 讨论的是结果读取，不能用它修复输入参数绑定；PDO::FETCH_ASSOC 只决定结果按列名组织，不是类型转换开关。

因此，排查时应分别记录输入值的业务语义、PHP 值类型、绑定方式、驱动环境和结果列类型。不能仅凭“数据库里存对了”推断参数一定按预期类型发送，也不能凭结果字符串断定原生预处理未启用。本文没有读取这些运行状态，示例只表达应采用的配置与判断方法。

占位符还只能代表完整数据值，不能用来绑定表名、列名或 ASC/DESC。需要动态排序时使用事先定义的允许列表；原生准备模式下也应避免重复使用同一个命名参数来代表多个位置，而是为各位置使用独立名称。

只写 execute 数组可以满足所有类型需求吗？

不适合把它当作明确类型绑定的替代。对于分页整数、可空值或字段语义敏感的情况，优先写出绑定类型，并使用不带数组的 execute。

关闭模拟就绝不会发生数据库类型转换吗？

不会。原生准备也不取消 SQL 列类型与表达式的转换规则。需要的应是明确的类型意图，而不是跨语言、驱动和数据库的无条件类型保真承诺。

这套写法可以原样用于 SQLite 或 PostgreSQL 吗？

不能把 PDO_MYSQL 的连接属性与行为直接推广到所有驱动。保留“输入验证、明确绑定、分开理解结果”的思路，再查目标驱动支持的属性和类型映射。

官方参考：execute 参数数组说明、bindValue、prepare 与占位符、PDO_MYSQL 驱动。