php单例不能只靠static变量，因其无法阻止new或clone绕过控制，且多请求下易污染；可靠单例须私有构造、私有克隆、全局唯一入口，并禁用__wakeup防反序列化。
为什么 PHP 单例不能只靠 static 变量？
直接在类里用 static $instance 存实例，看似简单，但会出问题：如果多个请求（比如 CLI 脚本或并发 Web 请求）共享同一个进程（如 PHP-FPM 的 worker），static 变量可能被意外复用或污染；更关键的是，它无法阻止外部通过 new 实例化——单例的核心约束就失效了。
真正可靠的单例必须同时满足三点：私有构造、私有克隆、全局唯一访问入口。缺一不可。
-
__construct()和__clone()必须设为private，否则new Singleton()或clone $obj都能绕过控制 -
getInstance()必须是public static，且内部用static $instance缓存——这个static是方法级静态变量，作用域受控，比类属性更安全 - 如果类支持序列化（比如要存入 Redis），还得禁用
__wakeup()，否则反序列化会绕过getInstance()
标准单例写法（含防序列化和线程安全提示）
PHP 本身没有线程概念，但在 FPM 多 worker 场景下，“线程安全”实际指“避免不同请求间状态泄露”。标准写法如下：
class Database {
private static $instance = null;
private function __construct() {}
private function __clone() {}
private function __wakeup() { throw new Exception("Cannot unserialize singleton"); }
public static function getInstance(): self {
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
}
注意：self::$instance 初始值显式设为 null，避免未初始化时判断出错；返回类型声明 : self 能让 IDE 和静态分析工具更好识别。
- 不要用
isset(self::$instance)判断，因为null会被判定为未设置，而显式赋null后isset返回false，逻辑反而混乱 - 如果项目用了 OPcache，确保
opcache.save_comments=1（默认开启），否则 PHP 8.2+ 的某些反射行为可能影响单例检测逻辑 - 该写法在 CLI 模式下也有效，但要注意：每个 CLI 进程独立，
getInstance()在不同进程里返回的是各自进程内的唯一实例
什么时候不该用单例？
单例常被误用为“全局变量的遮羞布”。以下场景建议直接放弃单例：
- 需要不同配置的多个数据库连接（比如主从分离），硬塞进一个单例会导致耦合和难以测试
- 类依赖外部状态（如用户 session、HTTP 请求头），单例会把请求上下文污染成全局状态
- 单元测试中无法重置或替换依赖，导致测试用例相互干扰——这时应优先考虑依赖注入容器（如
container->get('logger')）
真正适合单例的，通常是无状态、高开销、且全局共用的资源：日志处理器（Monolog\Logger）、缓存客户端（Predis\Client）、配置管理器（Config 类）。
替代方案：依赖注入容器更灵活
现代 PHP 项目（Laravel、Symfony、Slim）基本不用手写单例，而是交由容器管理。例如使用 PHP-DI：
$container->set(Database::class, \DI\create()->shared());
shared() 表示该类在容器生命周期内只实例化一次，效果等同单例，但优势明显：
- 实例创建逻辑可配置（比如传入不同 DSN）
- 可轻松切换实现（如用
MockDatabase替换真实类做测试） - 容器自动处理构造函数依赖注入，无需手动调用
getInstance()
手写单例现在更多见于小型脚本或遗留系统改造。一旦项目引入 DI 容器，就别再维护自定义单例——那只是重复造轮子，还容易漏掉 __wakeup 这种细节。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
