https://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/resources.html
java.net.URL
classpath：类路径：
就是应用的源码路径：tomcat/webapps/应用/源码文件夹
- ServletContext
遗憾的是，Java的标准java.net.URL类和各种URL前缀的标准处理程序不足以完全访问低级资源。 例如，没有标准化的URL实现可用于访问需要从类路径或相对于ServletContext获取的资源。 虽然可以为专用URL前缀注册新的处理程序（类似于http :)这样的前缀的现有处理程序，但这通常非常复杂，并且URL接口仍然缺少一些理想的功能，例如检查存在的方法 被指向的资源。
资源路径：
应用的类路径：classpath:
操作系统的文件路径： FileSystemXmlApplicationContext:
Url路径： file: for accessing filesystem paths, http: for accessing resources via the HTTP protocol, ftp: for accessing resources via FTP, etc.
ApplicationContext
- ClassPathXmlApplicationContext
- FileSystemXmlApplicationContext
Spring的Resource接口旨在成为一个更强大的接口，用于抽象对低级资源的访问。
6.3 Built-in Resource implementations
6.3.1 UrlResource
UrlResource包装java.net.URL，可用于访问通常可通过URL访问的任何对象，例如文件，HTTP目标，FTP目标等。所有URL都具有标准化的字符串表示形式，例如适当的标准化前缀用于表示来自另一个的一种URL类型。这包括文件：用于访问文件系统路径，http：用于通过HTTP协议访问资源，ftp：用于通过FTP访问资源等。
UrlResource是由Java代码使用UrlResource构造函数显式创建的，但是当您调用API方法时，通常会隐式创建它，该方法接受一个表示路径的String参数。对于后一种情况，JavaBeans PropertyEditor最终将决定要创建哪种类型的Resource。如果路径字符串包含一些众所周知的（对于它）前缀，例如classpath：，它将为该前缀创建适当的专用资源。但是，如果它无法识别前缀，则会假定这只是一个标准的URL字符串，并将创建一个UrlResource。
6.3.2 ClassPathResource
此类表示应从类路径获取的资源。 这使用线程上下文类加载器，给定的类加载器或给定的类来加载资源。
如果类路径资源驻留在文件系统中，则此Resource实现支持解析为java.io.File，但不支持驻留在jar中且尚未扩展（通过servlet引擎或任何环境）的类路径资源的解析 文件系统。 为了解决这个问题，各种Resource实现始终支持作为java.net.URL的解析。
ClassPathResource是由Java代码使用ClassPathResource构造函数显式创建的，但是当您调用一个API方法时，它通常会隐式创建，该方法接受一个表示路径的String参数。 对于后一种情况，JavaBeans PropertyEditor将识别字符串路径上的特殊前缀classpath：并在此情况下创建ClassPathResource。
class loader 加载资源
6.3.3 FileSystemResource
6.3.4 ServletContextResource
6.3.4 ServletContextResource
这是ServletContext资源的Resource实现，用于解释相关Web应用程序根目录中的相对路径。
这始终支持流访问和URL访问，但仅在扩展Web应用程序存档且资源实际位于文件系统上时才允许java.io.File访问。 它是否在这样的文件系统上展开，或直接从JAR或其他地方（如DB）（可以想象）访问，实际上是依赖于Servlet容器。
6.3.5 InputStreamResource
给定InputStream的Resource实现。 只有在没有适用的特定资源实现时才应使用此方法。 特别是，在可能的情况下，更喜欢ByteArrayResource或任何基于文件的资源实现。
与其他Resource实现相比，这是已打开资源的描述符 - 因此从isOpen（）返回true。 如果需要将资源描述符保留在某处，或者需要多次读取流，请不要使用它。
6.3.6 ByteArrayResource
这是给定字节数组的Resource实现。 它为给定的字节数组创建一个ByteArrayInputStream。
它对于从任何给定的字节数组加载内容非常有用，而无需使用一次性使用的InputStreamResource。
6.4 The ResourceLoader
ResourceLoader接口旨在由可以返回（即加载）Resource实例的对象实现。
所有应用程序上下文都实现ResourceLoader接口，因此可以使用所有应用程序上下文来获取Resource实例。
当您在特定应用程序上下文上调用getResource（）并且指定的位置路径没有特定前缀时，您将返回适合该特定应用程序上下文的Resource类型。 例如，假设针对ClassPathXmlApplicationContext实例执行了以下代码片段：
Resource template = ctx.getResource("some/resource/path/myTemplate.txt");
将返回的是ClassPathResource; 如果对FileSystemXmlApplicationContext实例执行相同的方法，则会返回FileSystemResource。 对于WebApplicationContext，您将获得ServletContextResource，依此类推。
因此，您可以以适合特定应用程序上下文的方式加载资源。
另一方面，您也可以通过指定特殊的类路径来强制使用ClassPathResource，而不管应用程序上下文类型如何：prefix：
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
类似地，可以通过指定任何标准java.net.URL前缀来强制使用UrlResource：
Resource template = ctx.getResource("file:/some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("http://myhost.com/resource/path/myTemplate.txt");
下表总结了将字符串转换为资源的策略：
6.5 The ResourceLoaderAware interface
当类实现ResourceLoaderAware并部署到应用程序上下文（作为Spring管理的bean）时，它被应用程序上下文识别为ResourceLoaderAware。 然后，应用程序上下文将调用setResourceLoader（ResourceLoader），将其自身作为参数提供（请记住，Spring中的所有应用程序上下文都实现了ResourceLoader接口）。
当然，由于ApplicationContext是一个ResourceLoader，bean也可以实现ApplicationContextAware接口并直接使用提供的应用程序上下文来加载资源，但一般情况下，最好使用专用的ResourceLoader接口，如果只需要它。 代码只会耦合到资源加载接口，可以将其视为实用程序接口，而不是整个Spring ApplicationContext接口。
从Spring 2.5开始，您可以依赖ResourceLoader的自动装配作为实现ResourceLoaderAware接口的替代方法。 “传统”构造函数和byType自动装配模式（如第5.4.5节“自动装配协作者”中所述）现在能够分别为构造函数参数或setter方法参数提供ResourceLoader类型的依赖项。 为了获得更大的灵活性（包括自动装配字段和多参数方法的能力），请考虑使用新的基于注释的自动装配功能。 在这种情况下，只要有问题的字段，构造函数或方法带有@Autowired注释，ResourceLoader就会自动装入一个期望ResourceLoader类型的字段，构造函数参数或方法参数。 有关更多信息，请参见第5.9.2节“@Autowired”。
6.6 Resources as dependencies
如果bean本身将通过某种动态过程确定并提供资源路径，那么bean使用ResourceLoader接口加载资源可能是有意义的。 以某种模板的加载为例，其中所需的特定资源取决于用户的角色。 如果资源是静态的，那么完全消除ResourceLoader接口的使用是有意义的，只需让bean公开它需要的Resource属性，并期望它们被注入到它中。
然后注入这些属性变得微不足道的是，所有应用程序上下文都注册并使用特殊的JavaBeans PropertyEditor，它可以将String路径转换为Resource对象。 因此，如果myBean具有Resource类型的模板属性，则可以使用该资源的简单字符串进行配置，如下所示：
<bean id="myBean" class="...">
<property name="template" value="some/resource/path/myTemplate.txt"/>
</bean>
请注意，资源路径没有前缀，因为应用程序上下文本身将用作ResourceLoader，资源本身将通过ClassPathResource，FileSystemResource或ServletContextResource（根据需要）加载，具体取决于上下文的确切类型。
如果需要强制使用特定的资源类型，则可以使用前缀。 以下两个示例显示如何强制ClassPathResource和UrlResource（后者用于访问文件系统文件）。
<property name="template" value="classpath:some/resource/path/myTemplate.txt">
<property name="template" value="file:/some/resource/path/myTemplate.txt"/>
6.7 Application contexts and Resource paths
6.7.1 Constructing application contexts
应用程序上下文构造函数（对于特定的应用程序上下文类型）通常将字符串或字符串数组作为资源的位置路径（例如构成上下文定义的XML文件）。
当这样的位置路径没有前缀时，从该路径构建并用于加载bean定义的特定资源类型依赖于并且适合于特定的应用程序上下文。 例如，如果您创建ClassPathXmlApplicationContext，如下所示：
ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
bean定义将从类路径加载，因为将使用ClassPathResource。 但是，如果您按如下方式创建FileSystemXmlApplicationContext：
ApplicationContext ctx =
new FileSystemXmlApplicationContext("conf/appContext.xml");
bean定义将从文件系统位置加载，在这种情况下相对于当前工作目录。
请注意，在位置路径上使用特殊类路径前缀或标准URL前缀将覆盖为加载定义而创建的默认Resource类型。 所以这个FileSystemXmlApplicationContext ......
ApplicationContext ctx =
new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
...实际上将从类路径加载其bean定义。 但是，它仍然是FileSystemXmlApplicationContext。 如果它随后用作ResourceLoader，则任何未加前缀的路径仍将被视为文件系统路径。
