应封装带参数绑定的执行流程和统一错误上下文，而非万能query()；事务用闭包封装避免漏rollback；默认禁用持久连接防状态残留；加参数校验与真实预处理提升调试效率。
为什么直接用 PDO::query 而不封装成 query() 方法
很多新手写 DB 工具类第一反应是封装 query()，结果发现参数绑定、错误处理、事务控制全得自己补，反而比原生 PDO 更难维护。PDO 本身已提供 prepare() + execute() 的安全路径，硬套一个万能 query() 容易忽略 SQL 注入风险。
真正该封装的是「带参数绑定的执行流程」和「统一错误上下文」：
-
select($sql, $params)：只读操作，返回关联数组，自动fetch(PDO::FETCH_ASSOC) -
insert($sql, $params)：返回lastInsertId()，不返回结果集 -
update($sql, $params)：返回rowCount()，便于判断是否真有数据被改 - 所有方法内部统一设置
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
事务中如何避免手动 try/catch 嵌套
手动写 beginTransaction() → commit() → rollback() 很容易漏掉回滚，尤其多层调用时。更稳的做法是把事务逻辑收进一个闭包参数：
$db->transaction(function ($db) {
$db->insert('INSERT INTO users (name) VALUES (?)', ['Alice']);
$db->insert('INSERT INTO profiles (user_id, bio) VALUES (?, ?)', [1, 'dev']);
});
这个 transaction() 方法内部做三件事：开启事务、执行闭包、成功则 commit，抛异常则 rollback 并 re-throw。不用在业务代码里显式 catch，也避免了嵌套层级过深时忘记 rollback。
立即学习“PHP免费学习笔记（深入）”；
连接复用与长连接的坑在哪
很多人以为加个 PDO::ATTR_PERSISTENT => true 就能提升性能，实际在 PHP-FPM 场景下容易引发状态残留问题——比如前一次请求设置了 SET NAMES utf8mb4，下次请求复用连接时可能没重置字符集，导致乱码；又或者前次事务没正常结束，连接被复用后直接报 SQLSTATE[HY000]: General error: 2006 MySQL server has gone away。
稳妥做法是：
- 默认关闭持久连接：
PDO::ATTR_PERSISTENT => false - 连接建立后立即执行初始化语句：
SET NAMES utf8mb4, time_zone = "+00:00" - 每次请求新建连接（PHP-FPM 下开销可控），靠连接池或数据库代理（如 ProxySQL）来优化底层复用
调试时怎么快速定位是 SQL 错还是参数错
开发中最烦的是报错信息只说 SQLSTATE[HY093]: Invalid parameter number，但不知道哪个占位符没传值，或者类型不匹配。工具类里应该加一层参数校验：
- 对
execute()前的$params数组，检查键名是否全在 SQL 中出现（命名参数）或长度是否匹配问号数量（位置参数） - 开启
PDO::ATTR_EMULATE_PREPARES => false，让错误真实来自 MySQL，而不是 PDO 模拟层的模糊提示 - 在开发环境开启日志，记录完整 SQL（替换好参数后的）和执行耗时，但注意别把密码之类敏感字段打出来
这类细节不体现在接口上，却决定你花 2 分钟还是 2 小时找到 bug。
