php单例模式能减少类实例化和重复connect()的cpu与内存开销，但不跨进程共享连接；在php-fpm下每个worker内仅创建一次pdo实例，连接复用需依赖pdo::attr_persistent及服务端配置。
PHP 单例模式真能减少数据库连接开销？
不能直接减少——它只保证「同一个 PHP 进程内」不重复 new 实例，但 PDO 或 mysqli 连接本身是否复用，取决于底层连接方式和 SAPI 模式。在 PHP-FPM 下，每个 worker 进程独立运行，Singleton::getInstance() 在该进程内只会创建一次连接；但不同请求打到不同 worker 时，连接仍是隔离的。所以单例节省的是「类实例化 + 重复 connect() 调用」的 CPU 和内存开销，不是跨进程共享连接。
为什么 FPM 场景下仍推荐单例封装数据库类？
因为避免了每次请求都执行 new Database() + $pdo = new PDO(...) 的重复逻辑。尤其当构造函数里做了配置加载、异常设置、属性初始化等操作时，单例能确保这些只跑一次。常见错误是把单例当成“全局连接池”，结果发现 too many connections 依然出现——那是因为没控制连接数上限，或没关闭长连接。
- 必须显式关闭连接（如调用
$pdo = null）才能释放句柄，单例本身不自动管理生命周期 - 若使用
PDO::ATTR_PERSISTENT => true，连接才可能被复用，但需配合数据库服务端配置（如wait_timeout） - FPM 子进程退出时会自动销毁所有资源，所以不手动 close 一般也不会泄漏，但高并发下连接堆积风险仍在
单例数据库类容易踩的坑有哪些？
最典型的是误以为「单例 = 连接复用」，进而忽略连接状态管理和错误恢复。比如：
-
__construct()中抛出异常后，self::$_instance仍为null，下次调用getInstance()会再试一次——可能反复失败并打满日志 - 没处理连接断开（如 MySQL server has gone away），后续查询直接 fatal error，而不是自动重连
- 在 CLI 脚本中使用单例，多个命令串行执行时，连接可能因超时失效，但单例不会感知
- 测试时难 mock：因为
Database::getInstance()是静态调用，无法注入假对象，导致单元测试必须连真实库或 patch 静态方法
比单例更稳妥的数据库连接管理方式
现代 PHP 项目中，直接手写单例数据库类已逐渐被替代。真正需要的是「连接可配置、可替换、可测试」的方案：
- 用依赖注入容器（如
PHP-DI）声明Database为 singleton scope，既能控制生命周期，又支持构造参数注入、装饰器包装（如加日志、重试） - 连接池交给扩展层处理（如
swoole_mysql或mysqlnd_ms），PHP 层只管获取连接句柄 - 对简单项目，用函数式封装（如
db_connect()）+static $conn缓存，比完整单例更轻量且不易误用
单例本身没问题，问题在于把它当作银弹——连接管理的复杂性，终究要靠连接池策略、超时控制、异常兜底来解决，而不是靠一个 getInstance() 方法。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
