单例模式在PHP中易掩盖耦合，依赖注入更可持续；若已用全局变量，单例可作过渡但须严控入口与生命周期。
直接说结论：单例模式在PHP中容易掩盖耦合，依赖注入才是更可持续的解法；但若项目已深陷全局变量泥潭，单例可作为过渡手段，前提是严格限制实例创建入口和生命周期。
为什么单例模式在PHP里常被误用？
PHP是无状态的请求级生命周期，static属性在一次请求内确实能“复用”，但单例常被写成带getInstance()的全局访问点，结果只是把$db换成了Database::getInstance()——本质仍是隐式依赖，测试时无法替换、重构时不敢动、并发下不安全（尤其用了static $instance但没加锁）。
常见错误现象：
- 多个类都调用
Config::getInstance()->get('host')，但没人知道Config从哪初始化、是否已加载配置文件 -
Logger::getInstance()内部硬编码了日志路径，导致无法在测试环境切换到NullLogger - 单例类构造函数里做了耗时操作（如连接数据库），而该实例只在某个边缘逻辑里才真正需要
依赖注入怎么落地？从参数传入开始
不需要立刻上容器或框架。最轻量的方式，就是把原本从全局拿的东西，改成由调用方明确传入。
比如原来这样：
function sendEmail($to, $subject) {
global $mailer;
return $mailer->send($to, $subject);
}
改成这样：
function sendEmail($to, $subject, $mailer) {
return $mailer->send($to, $subject);
}
使用场景：
- 函数/方法粒度小、调用链短时，直接传参最清晰
- 类的构造函数接收依赖，比在每个方法里
global干净得多 - 单元测试时可轻松传入
MockMailer，不用改任何生产代码
注意：$mailer不能是new Mailer()硬编码，否则又回到老路——它应由上层统一创建并传递。
什么时候该考虑容器？别早于路由入口
当项目里出现大量类似$userRepo = new UserRepository($pdo, $cache)这种嵌套依赖时，手动传递开始反人类。这时才引入容器（如PHP-DI或symfony/dependency-injection）。
关键约束：
- 容器实例**只应在入口文件（如
public/index.php）中构建一次**，之后不再全局暴露$container - 所有业务类必须通过构造函数声明依赖，禁止在类内部调用
$container->get() - 避免
ContainerInterface作为参数类型提示——那等于换汤不换药
一个典型错误是：在控制器里用$this->container->get('logger')，而不是把LoggerInterface作为构造参数。前者让类和容器强绑定，后者才能真正实现解耦。
超全局变量不是你的敌人，但别把它当胶水
$_GET、$_POST、$_SERVER这些是安全的——它们只读、不可写、来源明确。问题出在你用$GLOBALS或global $config去封装它们。
正确做法：
- 在入口处一次性提取并校验：
$request = new Request($_GET, $_POST, $_SERVER) - 后续所有业务逻辑只依赖
$request对象，而不是到处$_GET['id'] - 把
$_SESSION封装成SessionInterface，避免直接操作$_SESSION['user_id']
真正难处理的，是那些本该属于领域模型却漂在全局的变量，比如$currentUser、$appEnv。它们不该存在，而应作为上下文对象传入需要它的服务中。
最后提醒一句：清理全局变量最难的不是技术，而是找出谁在哪个角落偷偷unset($GLOBALS['cache'])——建议先用grep -r "global " . --include="*.php"扫一遍，再逐个击破。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
