PHP PDO 怎样统一数字字段的返回类型

我在把 PDO 查询结果直接交给 JSON 接口时，最容易遇到的不是 SQL 写错，而是同一个数字字段在不同驱动或配置下表现成不同类型。PHP 官方手册提供了 PDO::ATTR_STRINGIFY_FETCHES：开启后，取出的非 null 值会按字符串处理；关闭时则保留默认取值行为。官方说明可从 https://www.php.net/manual/en/pdo.setattribute.php 查看。

如果你的接口契约要求数字字段统一为字符串，可以在创建 PDO 连接后开启 ATTR_STRINGIFY_FETCHES；如果业务需要真正的数值运算，则要保留驱动默认行为并在边界处显式转换。这个属性不会把 null 变成字符串。

• 统一输出：开启属性，让非 null 查询值按字符串进入应用数组。
• 默认语义：关闭属性，交给 PDO 驱动决定具体取值表现，不预设所有数字都是同一种 PHP 类型。
• null 边界：官方说明 null 保持不变，除非另外启用了 PDO::ATTR_ORACLE_NULLS 的特殊转换。
• 确认方式：读取连接属性，并用 get_debug_type 检查实际字段类型。

ATTR_STRINGIFY_FETCHES 解决的是什么问题

这个属性解决的是“取数层的类型契约”，不是 SQL 类型定义，也不是 JSON 编码器的格式开关。比如表中有一个整数主键和一个金额字段，应用可能希望它们都以字符串传给前端，以避免旧客户端把同一接口中的类型理解得不一致。此时可以把类型策略放在 PDO 连接层，而不是每次 fetch 之后再遍历数组改值。

需要注意“非 null”这三个字。PHP 手册对 PDO::ATTR_STRINGIFY_FETCHES 的描述是：强制所有取出的值（null 除外）按字符串处理。因此把它理解成“所有字段都变成字符串”并不准确，至少不能据此推断数据库中的 NULL 会变成空字符串。

怎样在创建 PDO 连接时统一为字符串

最稳妥的做法是在连接建立后立即设置属性，并让后续查询共享这个连接。下面的示例只演示连接层策略；异常处理仍然交给调用方，不把密码、连接串或真实业务数据写进接口返回。

 PDO::ERRMODE_EXCEPTION,
        // 让非 null 的查询值按字符串进入结果集。
        PDO::ATTR_STRINGIFY_FETCHES => true,
        // 让结果数组只保留列名，减少重复的数字索引。
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    ]
);

// 预处理只负责查询；数字字段的统一策略已由连接属性负责。
$stmt = $pdo->prepare(
    'SELECT id, total_amount, nickname FROM orders WHERE id = :id'
);
$stmt->execute(['id' => 1001]);
$order = $stmt->fetch();

// null 仍应按业务含义处理，不要用空字符串替代缺失值。
if ($order !== false && $order['total_amount'] !== null) {
    echo json_encode($order, JSON_UNESCAPED_UNICODE);
}
?>

这个设置的价值在于把规则集中在连接配置里：同一连接上的查询不需要各自写 (string)。不过“字符串化”只说明取数结果的表示方式，不改变数据库列本身的类型，也不会阻止你之后把某个值显式转换成整数或浮点数。

开启还是关闭：我会按消费场景做选择

我通常先看结果要去哪儿。如果结果直接进入兼容性要求较强的 JSON 接口、缓存载荷或日志字段，统一字符串能让消费方少处理一类类型差异；如果结果马上要参与金额计算、分页比较或数量判断，则更愿意保留驱动默认行为，在业务边界显式转换并检查异常。

这里的“关闭”不是说所有驱动都会返回理想的整数或浮点数，而是不给 PDO 增加“统一字符串化”的要求。PHP 手册也把这个属性描述为取值转换控制项，因此跨驱动代码仍然应该把关键字段的最终类型写在接口或领域层约定里。

怎样确认设置值和实际结果类型

排查时我会分两层看：先确认连接属性，再确认一次 fetch 之后的字段类型。PHP 官方手册说明，PDO::getAttribute() 可以读取连接属性；当前手册还记录了 PHP 8.4 起可以读取 PDO::ATTR_STRINGIFY_FETCHES 的变更。实际项目仍需按运行环境和驱动能力处理异常。

getAttribute(PDO::ATTR_STRINGIFY_FETCHES);
    var_dump($stringify);
} catch (PDOException $e) {
    // 某些驱动不支持读取特定属性时，保留异常信息给日志层。
    error_log($e->getMessage());
}

// 用类型检查观察真实结果，不要只看 var_dump 的视觉输出。
$stmt = $pdo->query('SELECT id, total_amount, deleted_at FROM orders LIMIT 1');
$row = $stmt->fetch(PDO::FETCH_ASSOC);
if ($row !== false) {
    var_dump([
        // 中文注释说明每个观察字段的用途。
        'id_type' => get_debug_type($row['id']),
        'amount_type' => get_debug_type($row['total_amount']),
        'deleted_at_type' => get_debug_type($row['deleted_at']),
    ]);
}
?>

如果开启属性后非 null 字段仍然没有得到预期表现，不要立刻在每个字段上加转换。先确认代码使用的是同一个 PDO 实例、属性设置发生在查询前，并检查当前驱动对该属性的支持。对 null 字段则应分别判断 === null，因为字符串化策略不负责填充缺省值。

数值计算、NULL 和接口边界怎么处理

字符串形式的数字在 PHP 中有时可以参与宽松运算，但这不应该成为接口契约。需要加总、排序或比较时，建议在明确的业务边界转换，并对空值和非法输入单独处理。输出给前端时，则按接口约定决定是否保留字符串，避免同一个字段在不同接口里一会儿是数字、一会儿是字符串。

如果系统已经有大量旧客户端依赖字符串数字，开启 ATTR_STRINGIFY_FETCHES 往往比逐接口改写更容易控制；如果正在设计新接口，则可以把字段类型写进接口文档，再决定连接层统一策略。无论选择哪一种，都不要把 null、空字符串和数字零混为一谈。

常见问题

开启 ATTR_STRINGIFY_FETCHES 后 null 会变成空字符串吗？

不会。PHP 官方说明该属性影响的是除 null 外的取值；如果还设置了 PDO::ATTR_ORACLE_NULLS 的特殊模式，null 的表现需要按那个属性单独判断。

关闭该属性后，数据库整数一定返回 PHP int 吗？

不能这样保证。关闭表示不强制字符串化，具体结果仍与 PDO 驱动、数据库列和运行环境有关。关键字段应通过实际类型检查和接口契约确认。

可以在每次 fetch 后统一强转吗？

可以，但要先明确每个字段的业务类型；盲目把整行都转成字符串会损失 null 语义，盲目转成数字也可能破坏标识符、长数字或带小数的字段。

getAttribute 读取不到 ATTR_STRINGIFY_FETCHES 怎么办？

按当前 PHP 版本和驱动能力处理。可以把属性设置作为连接配置记录，并用实际 fetch 的 get_debug_type 观察结果；如果驱动不支持读取属性，不要把读取失败误判成查询失败。