别滥用单例了，但这类场景你必须懂它 | PHP实战手记

每次开启新的数据库连接，都像是在无意义地重复搬砖。尤其在处理数据导入或高并发请求时，内存占用会悄悄爬坡，请求延迟也跟着往上窜。很多人习惯在脚本顶部写一堆全局变量，或者把同一个对象实例塞满函数参数。折腾几圈后发现，代码越来越臃肿，调试时还经常找不到源头。与其让结构失控，不如给核心类戴上“唯一性”的缰绳——这正是单例模式该上场的时候。

拆开来看，单例的逻辑非常朴素：私有化构造方法切断外部随意new的路径，静态属性充当唯一实例的保险箱，静态方法提供统一的领取通道。标准实现并不复杂：

class DbConnection {
    private static ?self $instance = null;

    private function __construct() { /* 初始化连接参数 */ }

    public static function getInstance(): self {
        if (self::$instance === null) {
            self::$instance = new self();
        }
        return self::$instance;
    }
}

代码能跑，但实际落地时常有暗礁。很多教程只讲语法，不提现代PHP的运行环境差异。在传统的PHP-FPM模式下，每个请求都是独立进程，单例主要用来减少连接握手开销与配置解析耗时。一旦项目迁移到Swoole、Workerman或RoadRunner这些常驻内存框架，静态变量的生命周期会与进程绑定，单例里残留的请求级状态若不手动清理，跨请求的数据串扰会让Bug极难定位。

真正适合单例的场景，往往围绕“全局状态托管”展开。比如应用级配置管理器，只需在首次请求时读取并缓存YAML或JSON，后续直接走内存访问。又或是统一收口的外部服务客户端（如OSS推送、短信网关），集中管理重试策略与限流阈值，比散落在各个业务文件里更符合开闭原则。

如果团队坚持在架构中保留单例，务必做好隔离设计。把实例生成逻辑抽离成独立工厂类，或者让单例实现明确定义的接口。测试时通过容器替换契约，就能轻松Mock出纯净环境，避免全局状态污染用例。对于追求纯依赖注入的项目，单例更适合当作过渡期的脚手架，随着业务复杂度上升，逐步将隐式全局依赖显式化，才是维持代码可演进性的正解。

设计模式没有标准答案，只有上下文匹配度。单例模式的核心价值不在于凑齐样板代码，而在于替你拦截重复创建的隐性成本，并强制收敛散落的全局引用。看清它的适用边界，该用时用，该撤就撤，项目节奏才能稳稳压在可控范围内。