最有效、成本最低的破局点是消除类内部的 new 操作，改用集中工厂函数创建依赖，再通过构造器注入，避免硬编码、提升可测性与可维护性。
直接改 new 是最有效、成本最低的破局点。不是先选框架，而是先让所有类不再自己 new 依赖——这一步做完，80% 的紧耦合就松动了。
把 new 从类内部拎出来，统一交给工厂函数
硬编码 new MySQLDatabase() 或 new UserRepository() 是耦合的根源。它让类既“用轮子”又“造轮子”，切换数据库、加日志拦截、写单元测试时全得改构造逻辑。
实际做法很简单：写一个集中创建服务的工厂函数，比如：
function createServices(): array
{
return [
'db' => new MySQLDatabase($_ENV['DB_HOST'], $_ENV['DB_USER']),
'logger' => new FileLogger('/var/log/app.log'),
'cache' => new RedisCache(new Redis()),
];
}
- 所有控制器、服务类只接收这些实例，不再自己
new - 测试时可轻松传入
MockDatabase或NullLogger - 环境切换只需改工厂函数，不碰业务类代码
- 注意：工厂返回数组或对象均可，但别在工厂里做复杂逻辑（如条件判断多个 DB 实现），那会把耦合转移到工厂里
用容器替代手工传参，解决依赖爆炸问题
当类依赖越来越多（__construct(A $a, B $b, C $c, D $d, ...)），手动传参不仅难维护，还容易漏传、错序。这时候需要一个容器来自动解析和组装。
立即学习“PHP免费学习笔记（深入）”；
最小可行容器只需支持三件事：绑定抽象到实现、管理单例、通过反射自动注入构造参数。
- 绑定接口到具体类：
$container->bind(LoggerInterface::class, FileLogger::class) - 注册单例服务：
$container->singleton(Config::class, fn() => new Config($configArray)) - 获取时自动解析：
$service = $container->get(OrderService::class)—— 容器会递归解析OrderService构造函数中所有类型提示的依赖 - ⚠️ 注意：自动装配（autowiring）对接口无效，必须显式
bind()，否则抛出EntryNotFoundException - 性能上，首次
get()有反射开销，但后续单例复用无额外成本
在 Laravel 中避免 app() 随意调用，改用构造器注入
很多人用 app(UserRepository::class) 在方法里临时取服务，这看似方便，实则重蹈 new 覆辙：隐藏了真实依赖，破坏可测试性，且无法被 IDE 正确识别类型。
- ✅ 正确姿势：在控制器或服务类的构造函数中声明依赖，Laravel 容器自动注入
- ❌ 错误姿势：
public function store(Request $request) { $repo = app(UserRepository::class); ... } - 如果确实需要运行时动态决定服务（比如根据用户角色选不同支付网关），应注入一个策略工厂，而不是直接
app() - Laravel 的
bind()和singleton()区别关键在生命周期：前者每次get()都新建实例，后者只建一次；误用会导致状态污染（如共享的缓存连接被重复初始化）
PhalApi 或自研容器要注意延迟初始化陷阱
像 PhalApi 的 $di->logger = 'PhalApi\Logger\FileLogger' 这种写法是延迟初始化，看着简洁，但容易忽略两个现实问题：
- 类名字符串硬编码：重构类名时 IDE 不会提醒你改容器注册项，运行时报
Class not found - 配置分散：数据库连接参数可能散落在
$di->db、$di->redis、$di->cache多个闭包里，不如统一收口到工厂函数中管理 - 更隐蔽的问题是：如果某个服务的构造函数抛异常（比如 Redis 连接失败），错误发生在第一次访问该属性时，而非应用启动阶段，排查困难
- 建议：即使使用 PhalApi，也优先用闭包注册，并在闭包里做基础健壮性检查（如验证配置是否存在）
真正难的不是写容器，而是坚持让每个新写的类都遵守“不 new、不 app()、不全局变量”的铁律。一旦放松，旧债未清又添新坑，解耦就永远停在“下一步”。
