spring文档的3.4.4.5节对此进行了很好的解释：
（请注意，以下“ userPreferences” Bean定义不完整）：
<bean id="userPreferences" scope="session"/><bean id="userManager" > <property name="userPreferences" ref="userPreferences"/></bean>
从上述配置中可以明显看出，单例bean’userManager’是通过对HTTP会话作用域bean’userPreferences’的引用注入的。这里的要点是’userManager’bean是单例的 …… 每个容器将被实例化一次，并且它的依赖项（在这种情况下，只有一个’userPreferences’bean）也将被注入（一次！ ）。
这意味着“（概念上）”“ userManager”将仅对完全相同的“ userPreferences”对象进行操作，即最初注入该对象的对象。
当你将HTTP会话范围的bean作为依赖项（通常）注入协作对象时，这不是你想要的。相反，我们想要的是每个容器一个单独的“ userManager”对象，然后在HTTP会话的整个生命周期中，我们希望查看并使用特定于所述HTTP会话的“ userPreferences”对象。
然后，你需要注入某种对象，该对象公开与UserPreferences类完全相同的公共接口（理想情况下是一个UserPreferences实例的对象），并且足够聪明，可以启动并获取实际的UserPreferences对象从我们选择的任何基本范围界定机制（HTTP请求，会话等）中选择。然后，我们可以将该代理对象安全地注入到’userManager’bean中，这将很高兴地不会意识到它所持有的UserPreferences引用是一个proxy。
在我们的例子中，当UserManager实例在依赖项注入的UserPreferences对象上调用方法时，它实际上将在代理上调用方法 …然后，代理将关闭并从（在这种情况下）获取实际的UserPreferences对象HTTP会话，并将方法调用委派到检索到的真实UserPreferences对象上。
这就是为什么在将请求范围，会话范围和globalSession作用域的Bean注入协作对象时需要以下正确且完整的配置的原因：
<bean id="userPreferences" scope="session"> <aop:scoped-proxy/></bean><bean id="userManager" > <property name="userPreferences" ref="userPreferences"/></bean>
