通常，当我需要将一个或多个服务注入另一个服务时，我会显式地注入每个服务。然而，在我的情况下，注入服务容器本身确实会让事情变得更容易。我知道这不是一个推荐的做法，但我很好奇阻止这种做法的技术原因是什么。这是合理的，比如它过于资源密集，还是更私人的感觉，它太乱了？
如果注入容器，则不会明确依赖关系。事实上，你比以前更加模糊了它们。如果你有这样的课。。。
class DocumentCreator(IFileNamer fileNamer, IRepository repository)
{ ... }
您可以看到依赖项是什么。您还可以为单元测试轻松地模拟这些依赖关系，以确保隔离DocumentCreator，并知道任何测试失败都是其代码的结果，而不是依赖关系中的代码。
另一方面，如果你这样做。。。
class DocumentCreator(IDependencyContainer container)
{ ... }
你已经模糊了依赖关系。如果不检查类的内部，您就无法知道它需要一个IFileNamer和一个IRepository。
您也不能轻易地知道为了测试DocumentCreator，需要在容器中放入哪些mock。嘲笑IDdependencyContainer对你没有任何帮助；您的类在测试中仍然会失败，因为容器不会包含IFileNamer和IRepository，除非您检查类的内部以确定它们是必需的。
您所描述的是ServiceLocator。在现代应用程序设计中，这被认为是一种反模式。本文介绍了原因。
我认为这种方法的主要问题是您不再清楚地看到依赖关系。另一个问题可能是测试更加困难。