其他人指出了普遍的问题(并且是有效的答案)，但我只想提供一个额外的评论:并不是说你永远不应该这样做，而是尽可能少地做。

通常这意味着它只执行一次:在引导期间。然后，它只是访问“根”bean，通过它可以解决其他依赖关系。这可以是可重用的代码，如基本servlet(如果开发web应用程序)。

但是，仍然有一些情况需要使用服务定位器模式。 例如，我有一个控制器bean，这个控制器可能有一些默认的服务bean，这些服务bean可以通过配置注入依赖项。 虽然这个控制器现在或以后还可以调用许多附加的或新的服务，但这些服务需要服务定位器来检索服务bean。

其他人指出了普遍的问题(并且是有效的答案)，但我只想提供一个额外的评论:并不是说你永远不应该这样做，而是尽可能少地做。

通常这意味着它只执行一次:在引导期间。然后，它只是访问“根”bean，通过它可以解决其他依赖关系。这可以是可重用的代码，如基本servlet(如果开发web应用程序)。

There is another time when using getBean makes sense. If you're reconfiguring a system that already exists, where the dependencies are not explicitly called out in spring context files. You can start the process by putting in calls to getBean, so that you don't have to wire it all up at once. This way you can slowly build up your spring configuration putting each piece in place over time and getting the bits lined up properly. The calls to getBean will eventually be replaced, but as you understand the structure of the code, or lack there of, you can start the process of wiring more and more beans and using fewer and fewer calls to getBean.

Spring的前提之一是避免耦合。定义和使用接口，DI, AOP，避免使用ApplicationContext.getBean():-)

其动机是编写不显式依赖Spring的代码。这样，如果您选择切换容器，就不必重写任何代码。

把容器想象成代码看不见的东西，神奇地提供它的需要，而不需要被要求。

依赖注入是“服务定位器”模式的对应。如果您打算按名称查找依赖项，那么您也可以摆脱DI容器，使用JNDI之类的东西。