PHP 单例模式与静态门面：无框架系统的架构选择

无框架的 PHP 系统里，单例和静态门面不是二选一，而是各管一段：**单例负责"有状态、要复用"的重资源（数据库连接、配置、缓存驱动），静态门面负责"无状态、随手调"的能力（缓存、定时任务、通知、记账）**。判断标准只有一条——这个对象有没有"当前值"，以及它需不需要被替换。

先把两个词说清：单例是生命周期约束，门面是调用方式

单例模式指保证一个类在单次请求内只有一个实例，并提供一个全局访问点；静态门面指用一组静态方法包装底层实现，调用方不关心背后是谁。两者解决的是不同维度的问题：单例约束"有几个、活多久"，门面约束"怎么调"。

所以一个类完全可以内部是单例、外部被静态门面暴露。结论：把单例和门面当成互斥的架构流派，是概念混淆，不是技术分歧。

单例该管什么：数据库、配置、缓存驱动

这三者是典型的"有状态重资源"：数据库连接要复用，一次请求里发十条 SQL 不该建十次连接；配置读一次就该常驻；缓存驱动握手有成本。它们需要被"持有"，所以适合单例。

落地上就是老三样：私有构造函数、静态 `getInstance()`、禁掉克隆与反序列化（PHP 8 里可用 `final` 类 + `__clone` 抛异常）。注意选择分支——单例的收益是省资源，代价是依赖关系隐式化。

注意点：单例不是"防 new 的银弹"。如果把二十个工具类都做成单例，你得到的不是架构，而是二十个全局变量，测试时无法替换、调用方看不出依赖。结论：只对真正有状态且构建成本高的对象用单例，其余一律不用。

静态门面该管什么：Cache、Cron、notify、记账

Clara BBS 这类无框架系统（PHP 7.4-8.5 + MySQL 5.7+，无需 Composer、无需命令行、无编译缓存）的公共设施就是标准门面形态：`Cache::remember` 一行拿缓存、`Cron::register` 注册定时任务（懒触发、零配置）、`notify` 发通知、货币记账 API 统一走账。

这类调用的共同点是无状态：调用方不关心底层是文件缓存还是 Redis，不关心任务表存在哪张表、谁在什么时候触发。门面把这层不确定性吃掉，换来的是插件生态的低门槛——系统有 156 个运行时插件钩子，插件放在 `content/plugins` 目录、保存即生效。插件作者只需要写一行 `Cache::remember(...)`，不需要 new 核心对象、不需要拿容器、更不需要读懂内部依赖图。

原则很硬：门面里不要放状态。一旦往静止类里塞可变静态属性，就会出现"跨请求串数据"的误判——PHP-FPM 下进程会被复用，但脚本每次重跑，静态属性并不残留，很多人在这里排查半天。

为什么无框架系统不做 DI 容器

结论：小系统里，DI 容器的间接层成本大于收益。容器要处理注册顺序、自动装配、元数据缓存、更深的错误堆栈；而 Clara BBS 的取向是"上传文件 → 访问 install → 完成"，覆盖文件即生效、无编译缓存这种可读可改的形态，恰恰是它的卖点。

替代方案是一个极小的服务定位器：只登记少数几个真需要替换的对象（数据库、缓存驱动、发信器），其余走静态门面。这样既保住了"改一行就生效"的手感，又留出了测试与多实现的口子。

落地四条规则

1. 判据先行：这个类有没有"当前值"？有 → 单例；没有 → 静态门面。
2. 门面类禁止可变静态属性，计数类状态必须提供 reset 方法。
3. 门面方法签名要窄。暴露 `Cache::remember($key, $ttl, $callback)` 这种意图明确的接口，而不是把底层驱动的二十个方法原样透传。
4. 需要"多实现"的地方走注册机制。比如 AI 智能回复插件的多提供商故障转移与竞速，本质是注册 + 排序 + 择优，而不是把某一家写死进门面。

单例和静态门面在无框架系统里是分工而不是对立：前者守住有状态的共享资源，后者摊平无状态的公开能力；真正要警惕的从来不是这两个模式，而是把它们当万能胶，到处粘出一个隐式的全局状态网。