递归依赖注入图是否有害？代码递归运行正常是不良信号吗？

没错，循环（递归）依赖注入通常被视为不良实践，你代码里出现的这种循环引用绝对是需要警惕的设计信号——虽然PHP运行时没报错，但背后藏着不少维护隐患。

先看看你的代码里的问题：Test1依赖Test3，Test3依赖Test2，Test2又依赖Test1，形成了一个完整的依赖闭环。这种结构之所以不推荐，主要有这些原因：

• 职责边界模糊，违反单一职责原则：循环依赖往往意味着类之间的职责耦合过紧，本该独立的功能被硬绑在了一起。比如你的三个类互相依赖，很可能它们各自承担了超出自身范围的责任，本该拆分的逻辑被交叉纠缠了。
• 维护成本飙升：后续修改其中任意一个类时，都可能牵连到另外两个；排查问题时更是容易陷入循环跟踪——调试Test1的逻辑，得追到Test3，再到Test2，最后又绕回Test1，大大增加了理解和修改的成本。
• 初始化风险：你现在用的是setter注入，所以能正常运行，但如果换成很多DI容器推荐的构造函数注入，会直接触发初始化死锁：你没法在创建Test1前先创建Test3，而创建Test3又需要Test2，Test2又依赖Test1，根本无法完成初始化。
• 序列化/反序列化问题：就像你用var_dump()看到的递归引用，当你尝试序列化这些对象时，PHP会直接抛出错误——它默认无法处理循环引用的序列化，就算专门做兼容处理，也会额外增加复杂度。

怎么修复这种循环依赖？ #

最根本的解决方式是重构代码，理清类的职责：

1. 拆分共享逻辑：找出三个类中交叉依赖的功能，抽离成一个独立的公共类。比如如果它们都在处理同一种数据或业务逻辑，就把这部分逻辑放到新的SharedService里，让三个类都依赖这个服务，而非互相依赖。
   示例代码：

   // 抽离共享逻辑到独立类
   class SharedService {
       // 存放原本三个类交叉依赖的业务逻辑
       public function commonOperation() {
           // ...
       }
   }
   
   class Test1 {
       private $sharedService;
       public function __construct(SharedService $sharedService) {
           $this->sharedService = $sharedService;
       }
   }
   
   class Test2 {
       private $sharedService;
       public function __construct(SharedService $sharedService) {
           $this->sharedService = $sharedService;
       }
   }
   
   class Test3 {
       private $sharedService;
       public function __construct(SharedService $sharedService) {
           $this->sharedService = $sharedService;
       }
   }
   
   // 初始化不再有循环
   $sharedService = new SharedService();
   $test1 = new Test1($sharedService);
   $test2 = new Test2($sharedService);
   $test3 = new Test3($sharedService);
   

2. 引入中介者模式：创建一个中介类来协调三个类的交互，让它们不再直接依赖彼此，而是通过中介类传递数据或调用方法，打破闭环。
3. 延迟加载（权宜之计）：如果暂时无法重构，可以考虑在需要用到依赖时才初始化（比如在方法内部创建依赖实例），但这只是临时解决方案，不能从根本上解决设计问题，还可能隐藏更多风险。

总的来说，循环依赖不是语法错误，但它是代码设计的“坏味道”，提醒你需要重新审视类的职责划分。尽早重构消除循环依赖，能让代码更清晰、更易维护。

内容的提问来源于stack exchange，提问作者John Smith