PHP单例模式必须私有化__construct、__clone和__wakeup方法，使用static::而非self::支持继承，且仅在单进程内有效；推荐用DI容器替代手写单例。
PHP单例模式必须用private构造和克隆方法
不封住__construct和__clone，别人随时能绕过单例直接new出新实例，整个模式就失效了。常见错误是只私有化构造函数，忘了__clone——反序列化或显式调用clone后，会意外产生第二个对象。
-
__construct必须private，否则new Singleton()畅通无阻 -
__clone必须private，否则clone $instance能复制出副本 - 如果类支持反序列化，还得加
__wakeup并设为private，否则unserialize()也会新建实例
静态getInstance()里不能用self::硬编码类名
硬写self::会让子类无法继承单例行为——子类调用getInstance()返回的还是父类实例。要用static::实现后期静态绑定，确保每次返回的是「当前调用类」的唯一实例。
- 写
return new self();→ 返回定义该方法的类，不是调用者类 - 写
return new static();→ 返回实际调用getInstance()的那个类 - 配合
static $instances = [];按类名做键缓存，避免父子类共用一个实例
多线程环境下PHP单例不安全，别信“全局唯一”
PHP-FPM 是进程模型，每个请求在独立进程中执行；CLI 脚本也是单进程。所谓“全局唯一”只在一个请求/进程内成立。不存在跨进程、跨请求的单例——你无法靠单例在两个HTTP请求间共享数据库连接或配置状态。
- Web 场景中，每次请求都是新进程/新线程，
$instance变量完全隔离 - 想跨请求共享数据，得用
Redis、APCu或文件锁，不是靠单例 - CLI 长进程（如队列消费者）里单例才真正有意义，但要注意资源泄漏风险
替代方案比手写单例更可靠：容器+依赖注入
手写单例容易漏掉__wakeup、写错static::、忘记处理继承，而且测试困难——无法轻松替换依赖。现代 PHP 项目更倾向用 PSR-11 兼容容器（如PHP-DI或Laravel IoC），把“单例”变成配置项。
- 容器里声明
singleton或shared作用域，自动处理构造/克隆/反序列化 - 单元测试时可直接
container->set()注入模拟对象，不用改类代码 - 类本身彻底解耦，不再感知“自己是不是单例”，职责更清晰
单例最难的不是写出来，是判断“真需要它”。多数时候你以为要复用一个Logger，其实只是没把依赖传进去；以为要防止多次连DB，其实该用连接池或持久化连接。先确认问题本质，再决定要不要上单例。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
