首先我没有否认全局变量$services的作用，但我觉得它有巨大的改进和提升的空间，你不觉得目前$services对类单例属性仅仅只能配置字符串等标量而不能注入别的依赖类，很弱吗。

如果在array配置每个service时，还能直接把这个serviceA依赖的别的serviceB、serviceC等都直接配置到serviceA的属性上，那么我们就可以玩更多，

比如fecmall对每个service对象调用魔法方法时前后hook这是一个方法，不过我更推荐使用代理模式，在神X创建每个service时可以通过创建代理类来代理这个service，实现hook方法调用。

关于三方开发者插件开发、用户自己开发、fecmall自身升级之间的冲突，我觉得冲突是不可避免的，和包管理那样严格限制允许版本号呗，话说回来如果代码调用都是遵守同一个interface接口，每个service行为没问题就ok，interface依赖没有改变就可以认为没有冲突。

我QQ上面的回复没有说清楚，而且打错了几个字，

""" 最大的耦合就是全局变量$services自身，耦合体现在service之间的依赖全部靠全局变量来获取。正确的做法是应该靠语言本身类之间构造函数或者setter方法等来传递service之间的依赖，每个service应该对全局变量$services保持未知，只声明需要什么依赖。 """

用楼主说的例子，目前fecmall的状态，A、D是同种零件生产者，B是车企，B定义了这种零件的行业标准C，每次B要这种零件时都要先膜拜全知全能的神X来获取符合C标准的零件。

这个神X无处不在，系统里每个想要正常运行的部件都需要先膜拜神X。

不觉得这样很痛苦吗，作为开发者我要写代码就先要了解这个全能的神，把所有对神array merge的配置都看一遍，这些配置还都凌乱在各个地方，然后我写的每个部件，这个部件干每一件事就会大喊“万能的神啊给我一个xxx”。

正确的做法是让每个部件对神X保持未知，他们的依赖在神X创造完他们时他们已经知道了，就比如车企B，只依赖行业标准C，而不依赖零件厂A、D，更不依赖万能的神X。