PDO是数据库抽象层，支持多库切换、预处理防注入、异常报错；mysqli专为MySQL设计，性能优但不可移植，错误处理需手动检查，迁移时需重写全部逻辑。
原生 PHP 开发中，从 mysqli 迁移到 PDO 不是“升级”，而是为后续维护、测试和扩展留出确定性空间——尤其当你开始写单元测试、换数据库、或多人协作时，PDO 的抽象层会立刻显现出不可替代的价值。
为什么 PDO 的预处理默认更安全，而 mysqli 容易踩坑
PDO 在启用 PDO::ATTR_EMULATE_PREPARES => false（默认值）时，把 SQL 结构和参数真正交由 MySQL 服务端编译，完全分离；mysqli 的 prepare() 虽然也走服务端预处理，但一旦连接中断重连（比如 mysqli.reconnect=On）、或云数据库禁用 prepare 功能，它会静默退化为模拟预处理，且不报错。
常见错误现象：
- 本地能跑通的
WHERE name LIKE ?，上线后报SQLSTATE[HY000]: General error: 2031 - 用
bind_param('s', $val)时类型字符写错（比如写成'i'却传字符串），结果查不到数据，也不报错 - 误以为
mysqli_real_escape_string()能防所有注入，却在ORDER BY ?或LIMIT ?, ?处直接拼接变量
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有动态值一律走
prepare() + bindParam()，哪怕只是LIMIT参数 - 表名、字段名、排序方向等标识符不能绑定，必须白名单校验，例如：
in_array($sort, ['created_at', 'name']) ? $sort : 'id' - 不要依赖
mysqli_real_escape_string()做安全兜底，它只对字符串有效，且在连接字符集与客户端声明不一致时可能失效
切换数据库时，PDO 只改一行 DSN，mysqli 需重写全部逻辑
当项目需要从 MySQL 迁到 PostgreSQL，或测试阶段想用 SQLite 内存库，PDO 只需改 DSN：mysql:host=localhost;dbname=test → sqlite:/tmp/test.db，其余 prepare()/execute()/fetch() 代码全都不动。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
mysqli 是 MySQL 专属，函数名（mysqli_insert_id() vs PDO::lastInsertId()）、错误码、事务控制方式（mysqli_autocommit() vs $pdo->beginTransaction()）、甚至 last_insert_id() 的行为都不同。
使用场景：
- CI/CD 测试环境用 SQLite，生产用 MySQL：PDO 可以共用同一套 DAO 层
- 微服务中部分模块未来要接入 PostgreSQL：提前用 PDO，避免后期大规模重构
- 团队里有人熟悉 Python 的
psycopg2或 Node.js 的pg，统一占位符风格（?或:name）降低认知成本
错误处理机制差异直接决定线上问题是否可定位
mysqli 默认静默失败：调用 query() 出错，不抛异常，只设 $mysqli->error，你得手动判断。很多老项目因此出现页面空白、日志无记录、复现困难的问题。
PDO 可设 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，一出错就抛 PDOException，配合 try/catch 清晰可控——但注意这个设置必须在 new PDO() 实例化时传入，封装成工厂函数后再 setAttribute() 是无效的。
容易忽略的点：
-
PDO的lastInsertId()在多库共用一个实例时可能返回错库 ID；mysqli的insert_id属于连接实例，更确定 -
PDO的PDO::FETCH_ASSOC必须显式设置，默认是数字索引，否则字段顺序变动会导致逻辑错乱 - 新手常漏掉
PDO::ATTR_DEFAULT_FETCH_MODE，导致fetch()返回混合索引数组，调试时字段名取不到
真正麻烦的不是选错扩展，而是混用——比如用 PDO 连接却调 mysqli_fetch_assoc()，这种错误不会立即报错，而是在某个边缘查询路径上突然崩掉，排查成本极高。抽象层的价值不在“多支持几种数据库”，而在让边界清晰、行为可预期、错误可捕获。
