PDO + mysqlnd 是 PHP 8.5.5 下最稳妥选择，因其支持真预处理、SSL 验证、压缩传输及异常驱动错误处理，且与现代框架兼容；持久连接仅限 PHP-FPM worker 内有效，CLI/Serverless 中禁用。
PHP 8.5.5 下 PDO 是默认更安全、更可控的选择
不是“必须用 PDO”，而是：在 PHP 8.5.5 环境中，PDO + mysqlnd 驱动组合，能同时满足现代应用对安全性、可维护性和底层性能的硬性要求。它不依赖废弃函数，也不绑定 MySQL 特有语法，是当前最稳妥的起点。
为什么 mysqlnd 驱动比 libmysql 更适合 PHP 8.5.5
mysqlnd 是纯 PHP 实现的 MySQL 驱动，从 PHP 5.3 起就是默认驱动，到 PHP 8.5.5 已完全成熟。它直接集成在 PHP 核心中，无需额外编译依赖，且支持关键特性：
-
PDO::ATTR_EMULATE_PREPARES => false可真正交由 MySQL 服务端预处理，杜绝模拟层绕过导致的注入风险 - 原生支持压缩传输（
PDO::MYSQL_ATTR_COMPRESS => true），在长连接或大数据量场景降低带宽开销 - SSL 连接配置更直观（
PDO::MYSQL_ATTR_SSL_CA、PDO::MYSQL_ATTR_SSL_CERT等），配合mysqlnd可验证证书链 - 不兼容旧版
libmysql的某些隐式类型转换逻辑，反而减少了意外行为（比如把0当成空字符串）
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION 不只是报错方式问题
在 PHP 8.5.5 中，错误处理机制进一步收紧，mysqli 默认仍返回 false 或警告，而 PDO 设为异常模式后，所有数据库错误都会抛出 PDOException，带来三点实际好处：
- 避免漏判失败：不用反复写
if (!$result) { ... }，异常会自然中断流程，强制你处理 - 堆栈清晰：异常包含完整 SQL、参数、错误码（如
HY000）、甚至服务端错误信息（取决于PDO::ATTR_EMULATE_PREPARES设置） - 与现代框架兼容：Laravel、Symfony 等均基于异常做事务回滚和日志追踪，
PDO开箱即用
注意：PDO::ERRMODE_SILENT 或 PDO::ERRMODE_WARNING 在生产环境等同于埋雷——尤其在 PHP 8.5.5 的严格类型检查下，未捕获的 warning 可能被升级为 TypeError。
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
持久连接（PDO::ATTR_PERSISTENT）在 PHP-FPM 下容易误用
PDO 支持持久连接，但它的行为和 mysqli 有本质差异：
- 启用方式是传入属性数组：
new PDO($dsn, $user, $pass, [PDO::ATTR_PERSISTENT => true]) - 它不会自动重连：一旦连接断开（如 MySQL 主动 kill），下次
execute()会直接抛出PDOException，不像mysqli_ping()可主动探测修复 - 连接复用只发生在同一 PHP-FPM worker 进程内；重启 worker 后，所有持久连接失效，不会累积“僵尸连接”
- 若搭配 ProxySQL 或 MaxScale 使用，
PDO完全无感——你只需把 DSN 的host换成代理地址，连接池逻辑由中间件接管
真正容易踩坑的是：在 CLI 或 Serverless 环境下启用 PDO::ATTR_PERSISTENT，它根本不起作用，还可能干扰连接超时控制。
复杂点在于：PDO 的抽象能力是双刃剑。当你需要调用 MySQL 特有函数（如 JSON_CONTAINS、全文索引 hint）或调试查询执行计划时，PDO 不提供 mysqli::get_warnings() 这类细粒度接口，得靠原始 SQL + SELECT @@warning_count 手动补位。
