PHP PDO 预处理语句绑定动态条件的安全写法

PHP PDO 绑定动态查询条件时，我会把问题拆成两部分：筛选值交给占位符，列名、排序方向和条件结构由代码里的固定片段决定。预处理并不会替已经拼进 SQL 的用户输入补上安全边界；查询执行失败，也不应该悄悄变成“没有记录”。

PHP 官方地址：https://www.php.net/。下面以 PHP 8、PDO_MYSQL 和文档列表查询为例，解释我的写法取舍；示例未在本文环境运行，不作为实测记录。

我会先把数据值和 SQL 结构分开

列表筛选经常同时带来两种“动态”：status 是用户选择的数据值，ORDER BY 后的排序表达式却属于语句结构。两者都叫动态，但不能用相同方式处理。PDO 手册明确，占位符表示完整的数据字面量，不能代替标识符、关键字或任意查询片段。PDO::prepare 官方说明

我不喜欢把所有筛选都塞进一条带大量空值判断的通用语句。对于少数可选条件，条件数组更容易看清“加了哪一项、绑定了什么”。这是一种可维护性取舍，不表示它一定具有更好的执行计划。

连接配置和读取权限不能省略

函数接收现成的 PDO 连接，调用前应显式配置 PDO::ATTR_ERRMODE 为 PDO::ERRMODE_EXCEPTION。本文的 PDO_MYSQL 示例建议将 PDO::ATTR_EMULATE_PREPARES 设置为 false，并在连接 DSN 中明确使用 utf8mb4；这不是所有 PDO 驱动的通用配置清单。连接凭据来自应用受控配置，不写进文章示例或错误响应。

列表接口使用的数据库账号只应拥有其业务所需的读取权限。预处理负责值与语句的分离，不负责鉴权。tenant_id 必须来自可信身份上下文，不能让请求随便提交另一个租户编号；即使编号以整数安全绑定，越权问题也不会自动消失。

动态筛选只拼固定片段

假设已有 documents 表，至少包含 id、tenant_id、title、status、created_at。下面返回最多 50 条记录：null 表示不限制状态，draft 或 published 表示明确筛选，其他状态直接拒绝；排序只接受 newest 和 oldest。

 'created_at DESC, id DESC',
        'oldest' => 'created_at ASC, id ASC',
    ];
    if (!array_key_exists($sort, $sortMap)) {
        throw new InvalidArgumentException('排序选项无效');
    }

    $where = ['tenant_id = :tenant_id'];
    if ($status !== null) {
        if (!in_array($status, ['draft', 'published'], true)) {
            throw new InvalidArgumentException('状态无效');
        }
        $where[] = 'status = :status';
    }
    // 拼接的只有固定片段；所有动态数据值另行绑定。
    $sql = 'SELECT id, title, status, created_at FROM documents WHERE '
        . implode(' AND ', $where)
        . ' ORDER BY ' . $sortMap[$sort] . ' LIMIT 50';
    $stmt = $pdo->prepare($sql);
    $stmt->bindValue(':tenant_id', $tenantId, PDO::PARAM_INT);
    if ($status !== null) {
        $stmt->bindValue(':status', $status, PDO::PARAM_STR);
    }

    // 连接使用异常模式；数据库错误向调用边界传播，不伪装成空列表。
    $stmt->execute();
    return $stmt->fetchAll(PDO::FETCH_ASSOC);
}

这里的 where 数组、排序映射、租户参数、状态参数、SQL 模板和 PDOStatement 是六个不同角色。数组只保存作者写死的条件，sortMap 只保存作者写死的排序表达式；来自调用方的 status 与 tenantId 从不直接拼入 SQL。

我选择 bindValue，是因为这里需要绑定调用时已经确定的值，并明确指定参数类型。它不是输入合法性检查：绑定整数之前，仍需要确认标识真实、合法且属于当前授权范围。bindParam 采用引用语义，适合某些重复执行场景，但本例没有使用它的必要。bindValue 参数说明

每个出现位置都使用独立占位符，不依赖重复使用同名参数的行为。扩展 IN 条件时也不要把数组或逗号分隔字符串塞进一个参数里；先限制集合规模，为每个值生成占位符，再逐个绑定。空集合究竟表示“不筛选”还是“无匹配”，必须由业务明确，不能随手省略条件。

我宁愿明确失败，也不返回假空列表

当不存在符合条件的数据时，fetchAll 返回的空数组是正常结果；连接、prepare 或 execute 发生异常则属于执行失败。函数故意不捕获后返回空数组，让上层错误边界处理 PDOException。否则前端看到“暂无记录”，排查时却无法知道查询根本没有成功。

上层可记录请求关联标识、查询模板标识和 SQLSTATE，向客户端返回通用失败信息；不直接公开驱动错误、数据库结构、凭据或完整筛选值。日志内容还应经过应用的访问控制与脱敏规则。PHP 手册描述了异常模式及 PDOException 的错误信息接口。PDO 错误处理

这套写法适合什么，不适合什么

它适合条件数量有限、排序选项清楚的列表读取。代价是每增加一种条件，就要同步维护条件片段、参数绑定和输入规则。对于复杂报表，不能指望这个短函数替代完整查询构造设计；对于海量数据，也需要另行讨论索引、分页和资源限制。

交给自己的项目使用前，我会让回归场景覆盖：无状态筛选、两个有效状态、非法状态、非法排序、不同租户和数据库执行错误。预期是非法输入明确拒绝、正常无匹配保持空数组、执行错误进入统一错误处理，而不是在这里编造一份已经运行成功的输出。

ORDER BY :column 能绑定列名吗？

不能用它表示动态标识符。应将受限选项映射到代码维护的列名与排序表达式，不能拼接原始请求值。

开启异常模式能防止 SQL 注入吗？

不能。异常模式解决错误传播；值绑定和受控语句结构才处理本文讨论的注入边界，权限控制仍需另外完成。

先拼接用户条件，再调用 prepare 可以吗？

prepare 不会撤销此前不安全的拼接。应从一开始就让用户数据只进入参数绑定通道，语句结构只来自代码允许的片段。