Resources

ResourceLoaderAware
Built-in Resource Implementations
ClassPathXmlApplicationContext
Wildcards
FileSystemResource Caveats
InputStreamSource
WritableResource :description: 本文讨论了 Spring 的 Resource 抽象，它允许以统一的方式访问不同类型的资源。Resource 接口表示可用于加载、读取和写入资源的对象。Spring 提供了多种内置的 Resource 实现（例如 UrlResource、ClassPathResource 和 FileSystemResource），每种实现都针对特定类型的资源进行了优化。应用程序上下文充当 ResourceLoader，它允许以应用程序上下文类型特定的方式加载资源。ResourcePatternResolver 接口扩展了 ResourceLoader，允许使用模式（例如 Ant 路径模式）解析资源位置。开发人员还可以实现 ResourceLoaderAware 接口以直接加载资源或使用基于注释的自动装配来注入 Resource 对象。

本章介绍了 Spring 如何处理资源以及如何在 Spring 中使用资源。它包括以下主题：

Introduction
The Resource Interface
Built-in Resource Implementations
The ResourceLoader Interface
The ResourcePatternResolver Interface
The ResourceLoaderAware Interface
Resources as Dependencies
Application Contexts and Resource Paths

Introduction

不幸的是，Java 的标准 java.net.URL 类和各种 URL 前缀的标准处理程序不足以完全用于访问低级资源。例如，没有用于访问需要从类路径或相对于 ServletContext 获取的资源的标准化 URL 实现方式。虽然可以注册专门的 URL 前缀的新处理程序（类似于 http: 等前缀的现有处理程序），但这通常非常复杂，并且 URL 接口仍然缺少一些理想的功能，例如检查所指向的资源是否存在的方法。

The `Resource` Interface

Spring 的 Resource 接口位于 org.springframework.core.io. 包中，旨在成为一个更强大的接口来抽象对低级资源的访问。以下列表提供了 Resource 接口的概述。请参阅 Resource javadoc 以了解进一步详情。

public interface Resource extends InputStreamSource {

	boolean exists();

	boolean isReadable();

	boolean isOpen();

	boolean isFile();

	URL getURL() throws IOException;

	URI getURI() throws IOException;

	File getFile() throws IOException;

	ReadableByteChannel readableChannel() throws IOException;

	long contentLength() throws IOException;

	long lastModified() throws IOException;

	Resource createRelative(String relativePath) throws IOException;

	String getFilename();

	String getDescription();
}

正如 Resource 接口的定义所示，它扩展了 InputStreamSource 接口。以下列表显示了 InputStreamSource 接口的定义：

public interface InputStreamSource {

	InputStream getInputStream() throws IOException;
}

Resource 接口中一些最重要的方法是：

getInputStream()：找到并打开资源，返回一个 InputStream 从该资源中读取。每个调用都应返回一个新的 InputStream。由调用者负责关闭流。
exists()：返回一个 boolean，表示此资源实际上是否以物理形式存在。
isOpen()：返回一个 boolean，表示此资源是否表示具有打开流的句柄。如果为 true，则无法多次读取 InputStream，并且只能读取一次，然后关闭以避免资源泄漏。对于除 InputStreamResource 以外的所有常规资源实现，都返回 false。
getDescription()：返回此资源的描述，在使用该资源时要用于错误输出。通常是资源的完全限定文件名称或实际 URL。

其他方法允许你获取表示资源的实际 URL 或 File 对象（如果底层实现兼容并支持该功能）。

Resource 接口的一些实现也实现了扩展的 WritableResource 接口以获取支持对其写入的资源。

Spring 本身在需要资源时广泛使用 Resource 抽象，作为许多方法签名中的参数类型。某些 Spring API 中的其他方法（例如，到各种 ApplicationContext 实现的构造函数）使用一个 String，它以未修饰或简单形式用于创建适合该上下文实现的 Resource，或通过 String 路径上的专用前缀，允许调用者指定必须创建和使用的特定 Resource 实现。

虽然 Resource 接口在很多情况下与 Spring 及其本身一起使用，但它实际上非常方便，在你自己的代码中将其作为一般的实用程序类，用于访问资源，即使你的代码不知道或不关心 Spring 的任何其他部分。虽然这会将你的代码与 Spring 耦合，但实际上只将其与一小部分实用程序类耦合，这些类用作 URL 的更强大的替换，并且可以被视为你为此目的将要使用的任何其他库的等效项。

Resource 抽象不取代功能。它在可能的情况下对功能进行包装。例如，UrlResource 封装一个 URL 并使用被封装的 URL 来完成它的工作。

Built-in `Resource` Implementations

Spring 包括几个内置的 Resource 实现：

UrlResource
ClassPathResource
FileSystemResource
PathResource
ServletContextResource
InputStreamResource
ByteArrayResource

对于在 Spring 中可用的 Resource 实现的完整列表，请参阅 Resource javadoc 的“所有已知实现类”部分。

`UrlResource`

UrlResource 封装一个 java.net.URL，可以用于访问任何通常可以使用 URL 访问的对象，例如文件、HTTPS 目标、FTP 目标等。所有 URL 都有标准的 String 表示形式，以便使用适当的标准化前缀来指示一种 URL 类型与另一种 URL 类型。这包括 file:（用于访问文件系统路径）、https:（用于通过 HTTPS 协议访问资源）、ftp:（用于通过 FTP 访问资源）等。

UrlResource 是通过明确使用 UrlResource 构造函数由 Java 代码创建的，但在你调用获取一个表示路径的 String 参数的 API 方法时通常会隐式创建 UrlResource。对于后一种情况，一个 JavaBeans PropertyEditor 最终决定创建哪种类型的 Resource。如果路径字符串包含属性编辑器（即）公认的前缀（例如 classpath:），它会为该前缀创建一个适合的专门 Resource。但是，如果它不识别该前缀，它会假定该字符串是一个标准 URL 字符串，并创建一个 UrlResource。

`ClassPathResource`

此类表示应从类路径获取的资源。它使用线程上下文类加载器、给定的类加载器或给定的类加载资源。

此 Resource 实现支持将类路径资源解析为 java.io.File，如果类路径资源驻留在文件系统中，但对于驻留在 JAR 中且尚未展开（通过 servlet 引擎或无论环境是什么）到文件系统的类路径资源不支持。为了解决这个问题，各种 Resource 实现始终支持作为 java.net.URL 进行解析。

ClassPathResource 是通过明确使用 ClassPathResource 构造函数由 Java 代码创建的，但在你调用获取一个表示路径的 String 参数的 API 方法时通常会隐式创建 ClassPathResource。对于后一种情况，一个 JavaBeans PropertyEditor 识别字符串路径上的特殊前缀 classpath:，并在该情况下创建一个 ClassPathResource。

`FileSystemResource`

这是一个适用于 java.io.File 控制的 Resource 实现。它还支持 java.nio.file.Path 控制，使用 Spring 的标准基于字符串的路径转换，但通过 java.nio.file.Files API 执行所有操作。相反，对于基于 java.nio.path.Path 的纯支持，使用 PathResource。FileSystemResource 支持作为 File 和 URL 进行解析。

`PathResource`

这是一个适用于 java.nio.file.Path 控制的 Resource 实现，通过 Path API 执行所有操作和转换。它支持作为 File 和 URL 进行解析，还实现了扩展的 WritableResource 接口。PathResource 实际上是一个基于 java.nio.path.Path 的 FileSystemResource 的纯替代品，具有不同的 createRelative 行为。

`ServletContextResource`

这是一个适用于 ServletContext 资源的 Resource 实现，可以解释相关 Web 应用程序根目录内的相对路径。

它始终支持流访问和 URL 访问，但仅在 Web 应用程序存档已展开且该资源实际上存在于文件系统上时才允许 java.io.File 访问。它是否展开并存在于文件系统上，或者是否直接从 JAR 或数据库等其他地方（这是可以想象的）进行访问，实际上取决于 Servlet 容器。

`InputStreamResource`

InputStreamResource 是给定 InputStream 的 Resource 实现。仅当没有特定的 Resource 实现适用时才应该使用它。具体而言，在可能的情况下，优先使用 ByteArrayResource 或任何基于文件的 Resource 实现。

与其他 Resource 实现不同，这是一个已经打开的资源的描述符。因此，它从 isOpen() 返回 true。如果您需要将资源描述符保留在某个地方或需要多次读取流，请不要使用它。

`ByteArrayResource`

这是一个给定字节数组的 Resource 实现。它为给定的字节数组创建 ByteArrayInputStream。

这对于从任何给定的字节数组加载内容非常有用，而无需使用一次性 InputStreamResource。

The `ResourceLoader` Interface

ResourceLoader 接口旨在由可以返回（即，加载）Resource 实例的对象实现。以下列表显示了 ResourceLoader 接口定义：

public interface ResourceLoader {

	Resource getResource(String location);

	ClassLoader getClassLoader();
}

所有应用程序上下文都实现了 ResourceLoader 接口。因此，可以使用所有应用程序上下文来获取 Resource 实例。

当您在特定应用程序上下文中调用 getResource()，并且指定的 location path 没有特定前缀时，您会得到一个适合于特定应用程序上下文的 Resource 类型。例如，假设运行了以下代码段来针对 ClassPathXmlApplicationContext 实例：

Java
Kotlin

Resource template = ctx.getResource("some/resource/path/myTemplate.txt");

val template = ctx.getResource("some/resource/path/myTemplate.txt")

对于 ClassPathXmlApplicationContext，该代码返回 ClassPathResource。如果针对 FileSystemXmlApplicationContext 实例运行相同的方法，它将返回 FileSystemResource。对于 WebApplicationContext，它将返回 ServletContextResource。它同样会为每个上下文返回适当的对象。

因此，您可以以适合特定应用程序上下文的样式加载资源。

另一方面，您还可以强制使用 ClassPathResource，而不管应用程序上下文类型如何，方法是指定特殊的前缀 classpath:，如下例所示：

Java
Kotlin

Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");

val template = ctx.getResource("classpath:some/resource/path/myTemplate.txt")

同样，您可以通过指定任何标准的 java.net.URL 前缀来强制使用 UrlResource。以下示例使用前缀 file 和 https:

Java
Kotlin

Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt");

val template = ctx.getResource("file:///some/resource/path/myTemplate.txt")

Java
Kotlin

Resource template = ctx.getResource("https://myhost.com/resource/path/myTemplate.txt");

val template = ctx.getResource("https://myhost.com/resource/path/myTemplate.txt")

下表总结了将 String 对象转换为 Resource 对象的策略：

Table 1. Resource strings
Prefix	Example	Explanation
classpath:	`classpath:com/myapp/config.xml`	Loaded from the classpath.
file:	`file:///data/config.xml`	从文件系统加载 `URL`。另见 `FileSystemResource` Caveats。
https:	`https://myserver/logo.png`	Loaded as a `URL`.
(none)	`/data/config.xml`	依赖于底层的 `ApplicationContext`。

The `ResourcePatternResolver` Interface

ResourcePatternResolver 接口是对 ResourceLoader 接口的扩展，它定义了将位置模式（例如，Ant 风格路径模式）解析为 Resource 对象的策略。

public interface ResourcePatternResolver extends ResourceLoader {

	String CLASSPATH_ALL_URL_PREFIX = "classpath*:";

	Resource[] getResources(String locationPattern) throws IOException;
}

正如上面所见，此接口还定义了一个针对类路径中的所有匹配资源特殊 classpath*: 资源前缀。请注意，在这种情况下，资源位置应为不含占位符的路径，例如 classpath*:/config/beans.xml。JAR 文件或类路径中的不同目录可以包含具有相同路径和名称的多文件。有关使用 classpath*: 资源前缀通配符支持的更多详细信息，请参阅 Wildcards in Application Context Constructor Resource Paths 及其子部分。

可以检查传入 ResourceLoader（例如，通过 ResourceLoaderAware 语义提供的 ResourceLoader）是否也实现了此扩展接口。

PathMatchingResourcePatternResolver 是一个独立实现，可以在 ApplicationContext 外部使用，它也由 ResourceArrayPropertyEditor 用于填充 Resource[] bean 属性。PathMatchingResourcePatternResolver 能够将指定资源位置路径解析为一个或多个匹配的 Resource 对象。源路径可能是简单路径，它具有与目标 Resource 对应的一对一映射，或者可以包含特殊 classpath*: 前缀和/或内部 Ant 样式正则表达式（使用 Spring 的 org.springframework.util.AntPathMatcher 实用程序进行匹配）。后两者实际上都是通配符。

任何标准 ApplicationContext 中的默认 ResourceLoader 实际上是实现了 ResourcePatternResolver 接口的 PathMatchingResourcePatternResolver 的一个实例。对于 ApplicationContext 实例本身也是如此，它还实现了 ResourcePatternResolver 接口并将委托给默认的 PathMatchingResourcePatternResolver。

The `ResourceLoaderAware` Interface

ResourceLoaderAware 接口是一个特殊的回调接口，用于标识希望提供 ResourceLoader 引用。以下列表显示了 ResourceLoaderAware 接口的定义：

public interface ResourceLoaderAware {

	void setResourceLoader(ResourceLoader resourceLoader);
}

当一个类实现 ResourceLoaderAware 并部署到应用程序上下文中（作为 Spring 管理的 bean）时，应用程序上下体会将其识别为 ResourceLoaderAware。然后，应用程序上下文调用 setResourceLoader(ResourceLoader)，将自身作为参数提供（请记住，Spring 中的所有应用程序上下文都实现了 ResourceLoader 接口）。

由于 ApplicationContext 是一个 ResourceLoader，因此 bean 也可以实现 ApplicationContextAware 接口，并使用提供的应用程序上下文直接加载资源。但是，通常情况下，如果你只需要它，最好使用专门的 ResourceLoader 接口。代码只会与资源加载接口（可以认为是实用程序接口）耦合，而不会与整个 Spring ApplicationContext 接口耦合。

在应用程序组件中，你还可以依赖 ResourceLoader 的自动装配，而不是实现 ResourceLoaderAware 接口。traditional constructor 和 byType 自动装配模式（如 Autowiring Collaborators 中所述）能够分别为构造函数参数或 setter 方法参数提供 ResourceLoader 。为了获得更大的灵活性（包括自动装配字段和多参数方法的能力），请考虑使用基于注释的自动装配功能。在这种情况下，ResourceLoader 被自动装配到字段、构造函数参数或方法参数中，该字段、参数或方法期待 ResourceLoader 类型，只要有问题的字段、构造函数或方法带有 @Autowired 注释。有关更多信息，请参阅 Using @Autowired。

要加载一个或多个 Resource 对象的资源路径，其中包含通配符或使用特殊的 classpath*: 资源前缀，请考虑让 ResourcePatternResolver 的实例自动装配到应用组件中，而不是 ResourceLoader 。

Resources as Dependencies

如果 bean 本身要通过某种动态过程来确定和提供资源路径，那么 bean 使用 ResourceLoader 或 ResourcePatternResolver 接口来加载资源可能是有道理的。例如，考虑加载某种模板，其中所需的特定资源取决于用户角色。如果资源是静态的，那么完全取消使用 ResourceLoader 接口（或 ResourcePatternResolver 接口）是有道理的，让 bean 公开它需要的 Resource 属性，并期望它们被注入到其中。

使注入这些属性变得轻而易举的是，所有应用程序上下文都会注册并使用一个特殊的 JavaBeans PropertyEditor，它可以将 String 路径转换为 Resource 对象。例如，以下 MyBean 类有一个 template 属性，类型为 Resource。

Java
Kotlin

public class MyBean {

	private Resource template;

	public setTemplate(Resource template) {
		this.template = template;
	}

	// ...
}

class MyBean(var template: Resource)

在 XML 配置文件中，template 属性可以使用该资源的简单字符串进行配置，如下例所示：

<bean id="myBean" class="example.MyBean">
	<property name="template" value="some/resource/path/myTemplate.txt"/>
</bean>

请注意，资源路径没有前缀。因此，由于应用程序上下文本身将用作 ResourceLoader，因此该资源将通过 ClassPathResource、FileSystemResource 或 ServletContextResource 加载，具体取决于应用程序上下文的具体类型。

如果你需要强制使用特定的 Resource 类型，则可以使用前缀。以下两个示例展示了如何强制使用 ClassPathResource 和 UrlResource（后者用于访问文件系统中的文件）：

<property name="template" value="classpath:some/resource/path/myTemplate.txt">

<property name="template" value="file:///some/resource/path/myTemplate.txt"/>

如果 MyBean 类被重构以与注释驱动的配置一起使用，则 myTemplate.txt 的路径可以存储在名为 template.path 的键下——例如，在为 Spring Environment 提供的属性文件中（参见 Environment Abstraction ）。然后可以通过使用属性占位符（请参见 Using @Value）通过 @Value 注释来引用模板路径。Spring 会将模板路径的值检出为字符串，并且特殊的 PropertyEditor 将把字符串转换为要注入到 MyBean 构造函数中的 Resource 对象。以下示例演示了如何实现这一点。

Java
Kotlin

@Component
public class MyBean {

	private final Resource template;

	public MyBean(@Value("${template.path}") Resource template) {
		this.template = template;
	}

	// ...
}

@Component
class MyBean(@Value("\${template.path}") private val template: Resource)

如果我们希望支持在 classpath 中多个位置发现多个模板——例如，在 classpath 中的多个 jar 中——我们可以使用特殊 classpath*: 前缀和通配符将 templates.path 键定义为 classpath*:/config/templates/*.txt。如果我们重新定义 MyBean 类如下所示，Spring 会将模板路径模式转换为可以注入到 MyBean 构造函数中的 Resource 对象数组。

Java
Kotlin

@Component
public class MyBean {

	private final Resource[] templates;

	public MyBean(@Value("${templates.path}") Resource[] templates) {
		this.templates = templates;
	}

	// ...
}

@Component
class MyBean(@Value("\${templates.path}") private val templates: Resource[])

Application Contexts and Resource Paths

本节介绍如何使用资源创建应用程序上下文，包括使用 XML 的快捷方式、如何使用通配符以及其他详细信息。

Constructing Application Contexts

应用程序上下文构造函数（对于特定的应用程序上下文类型）通常使用字符串或字符串数组作为资源（例如构成上下文定义的 XML 文件）的位置路径。

如果这样的位置路径没有前缀，则从该路径构建并用于加载 bean 定义的特定 Resource 类型取决于特定应用程序上下文，并且适合该上下文。例如，考虑以下示例，它创建了一个 ClassPathXmlApplicationContext：

Java
Kotlin

ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");

val ctx = ClassPathXmlApplicationContext("conf/appContext.xml")

bean 定义从 classpath 加载，因为使用了 ClassPathResource。但是，考虑以下示例，它创建了一个 FileSystemXmlApplicationContext：

Java
Kotlin

ApplicationContext ctx =
	new FileSystemXmlApplicationContext("conf/appContext.xml");

val ctx = FileSystemXmlApplicationContext("conf/appContext.xml")

现在，bean 定义从文件系统位置加载（在本例中，相对于当前工作目录）。

请注意，在位置路径上使用特殊 classpath 前缀或标准 URL 前缀会覆盖创建用于加载 bean 定义的默认 Resource 类型。考虑以下示例：

Java
Kotlin

ApplicationContext ctx =
	new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");

val ctx = FileSystemXmlApplicationContext("classpath:conf/appContext.xml")

使用 FileSystemXmlApplicationContext 从 classpath 加载 bean 定义。但是，它仍然是 FileSystemXmlApplicationContext。如果随后将其用作 ResourceLoader，那么任何没有前缀的路径仍然会被视为文件系统路径。

Constructing `ClassPathXmlApplicationContext` Instances — Shortcuts

ClassPathXmlApplicationContext 公开了多个构造函数，以实现方便的实例化。基本思想是你可以提供一个只包含 XML 文件本身的文件名（没有前导路径信息）的字符串数组，还可以提供一个 Class。然后，ClassPathXmlApplicationContext 从提供的类派生出路径信息。

考虑以下目录布局：

com/ example/ services.xml repositories.xml MessengerService.class

以下示例展示了如何实例化一个 ClassPathXmlApplicationContext 实例，该实例由名为 services.xml 和 repositories.xml（位于 classpath 中）的文件中定义的 bean 组成：

Java
Kotlin

ApplicationContext ctx = new ClassPathXmlApplicationContext(
	new String[] {"services.xml", "repositories.xml"}, MessengerService.class);

val ctx = ClassPathXmlApplicationContext(arrayOf("services.xml", "repositories.xml"), MessengerService::class.java)

请参阅 ClassPathXmlApplicationContext javadoc 以了解有关各种构造函数的详情。

Wildcards in Application Context Constructor Resource Paths

应用程序上下文构造函数值中的资源路径可以是简单的路径（如前面所示），每个路径与目标`Resource`一一对应，或者包含特殊的`classpath*:`前缀或内部 Ant 风格模式（通过使用 Spring 的`PathMatcher`实用程序进行匹配）。后两者实际上都是通配符。

使用此机制的一种情况是需要执行组件式应用程序程序集的时候。所有组件都可以将上下文定义片段“发布”到已知的位置路径，并且当使用带有`classpath*:`前缀的相同路径创建最终的应用程序上下文时，将自动选取所有组件片段。

请注意，此通配符特定于应用程序上下文中使用资源路径（或直接使用`PathMatcher`实用程序类层次结构），并在构建时解析。它与`Resource`类型本身无关。无法使用`classpath*:`前缀来构建实际的`Resource`，因为资源一次只指向一个资源。

Ant-style Patterns

路径位置可以包含 Ant 风格模式，如下例所示：

/WEB-INF/-context.xml com/mycompany//applicationContext.xml file:C:/some/path/-context.xml classpath:com/mycompany//applicationContext.xml

当路径位置包含 Ant 风格模式时，解析器将遵循一个更复杂的程序来尝试解析通配符。它会为该路径（直到最后一个非通配符段）生成`Resource`，并从中获取 URL。如果此 URL 不是`jar:`URL 或特定于容器的变体（例如 WebLogic 中的`zip:`、WebSphere 中的`wsjar`等），将从该 URL 获取`java.io.File`并用它来遍历文件系统以解析通配符。对于 jar URL，解析器要么从中获取`java.net.JarURLConnection`，要么手动解析 jar URL，然后遍历 jar 文件的内容以解析通配符。

Implications on Portability

如果指定路径已经是`file`URL（隐式是因为基本`ResourceLoader`是文件系统资源加载器或显式），则保证以完全可移植的方式使用通配符。

如果指定路径是`classpath`位置，则解析器必须通过进行`Classloader.getResource()调用来获取最后一个非通配符路径段的 URL。由于这只是路径的一个节点（而不是末尾的文件），因此实际上是未定义的（在`ClassLoader`javadoc 中），在这种情况下将返回哪种类型的 URL。实际上，它始终是表示目录的`java.io.File（其中类路径资源解析到文件系统位置）或某种 jar URL（其中类路径资源解析到 jar 位置）。尽管如此，此操作仍存在可移植性问题。

如果为最后一个非通配符段获取 jar URL，则解析器必须能够从中获取`java.net.JarURLConnection`或手动解析 jar URL，以便能够遍历 jar 的内容并解析通配符。这在大多数环境中有效，但在其他环境中会失败，我们强烈建议在依赖它之前彻底测试来自 jar 的资源的通配符解析。

The `classpath*:` Prefix

构建基于 XML 的应用程序上下文时，位置字符串可以使用特殊的`classpath*:`前缀，如下例所示：

Java
Kotlin

ApplicationContext ctx =
	new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

val ctx = ClassPathXmlApplicationContext("classpath*:conf/appContext.xml")

此特殊前缀指定必须获取所有与给定名称匹配的类路径资源（在内部，这本质上是通过调用`ClassLoader.getResources(…)`实现的），然后合并以形成最终的应用程序上下文定义。

通配符类路径依赖于基础 ClassLoader 的 getResources() 方法。现如今大多数应用服务器都提供自己的 ClassLoader 实现，因此行为可能不同，尤其是在处理 jar 文件时。检查 classpath* 是否有效的一个简单测试是使用 ClassLoader 从类路径上的 jar 文件中加载一个文件：getClass().getClassLoader().getResources("<someFileInsideTheJar>")。尝试使用同名但位于两个不同位置的文件进行此测试——例如，类路径上不同 jar 中的同名同路径文件。如果返回不恰当的结果，请查看应用服务器说明以了解可能影响 ClassLoader 行为的设置。

您还可以将`classpath*:`前缀与位置路径的其余部分中的`PathMatcher`模式结合使用（例如，classpath*:META-INF/*-beans.xml）。在这种情况下，解析策略非常简单：对最后一个非通配符路径段使用`ClassLoader.getResources()`调用以获取类加载器层次结构中的所有匹配的资源，然后对每个资源均使用前面描述的相同`PathMatcher`解析策略进行通配符子路径解析。

Other Notes Relating to Wildcards

请注意，`classpath*:`在与 Ant 风格模式结合使用时，仅在模式开始之前至少有一个根目录时才能可靠地工作，除非实际目标文件驻留在文件系统中。这意味着这样的模式`classpath*:*.xml`可能无法从 jar 文件的根目录检索文件，而只能从已展开目录的根目录检索文件。

Spring 检索类路径条目的能力源自 JDK 的`ClassLoader.getResources()`方法，该方法仅为一个空字符串（表示要搜索的潜在根目录）返回文件系统位置。Spring 还评估`URLClassLoader`运行时配置和 jar 文件中的`java.class.path`清单，但这并不能保证达到可移植行为。

类路径包的扫描需要类路径中存在相应的目录项。使用 Ant 构建 JAR 时，请勿激活 JAR 任务的`files-only`开关。此外，类路径目录在某些环境中可能不会根据安全策略公开——例如 JDK 1.7.0_45 及更高版本上的独立应用程序（这需要在清单中设置“受信任库”。请参阅 https://stackoverflow.com/questions/19394570/java-jre-7u45-breaks-classloader-getresources）。在 JDK 9 的模块路径（Jigsaw）上，Spring 的类路径扫描通常按预期执行。在此处将资源放入专门的目录也强烈推荐，这样可以避免使用前面提到的可移植性问题搜索 jar 文件的根级别。

如果要搜索的根包在多个类路径位置中可用，则使用`classpath:`资源的 Ant 风格模式并不能保证找到匹配的资源。考虑以下资源位置的示例：

com/mycompany/package1/service-context.xml

现在考虑可能有人用来尝试查找该文件的 Ant 风格路径：

classpath:com/mycompany/**/service-context.xml

这样的资源可能只存在于类路径中的一个位置，但是当使用如前例所示的路径来尝试解析时，解析器以`getResource("com/mycompany");`返回的（第一个）URL 为依据。如果这个基本包节点存在于多个`ClassLoader`位置，则所需的资源可能不存在于找到的第一个位置。因此，在这种情况下，您应该更喜欢将`classpath*:`与相同的 Ant 风格模式一起使用，该模式搜索包含`com.mycompany`基本包的所有类路径位置： classpath*:com/mycompany/**/service-context.xml。

`FileSystemResource` Caveats

没有附加FileSystemApplicationContext（换句话说，当FileSystemApplicationContext不是实际ResourceLoader）时，将FileSystemResource视为您预期的那样处理绝对和相对路径。相对路径相对于当前工作目录，而绝对路径相对于文件系统的根目录。

然而，出于向后兼容性（历史）原因，当FileSystemApplicationContext是ResourceLoader时，这是改变的。FileSystemApplicationContext强制所有附加的FileSystemResource实例将所有位置路径视为相对，无论它们是否以前置斜线开头。实际上，这意味着以下示例是等效的：

Java
Kotlin

ApplicationContext ctx =
	new FileSystemXmlApplicationContext("conf/context.xml");

val ctx = FileSystemXmlApplicationContext("conf/context.xml")

Java
Kotlin

ApplicationContext ctx =
	new FileSystemXmlApplicationContext("/conf/context.xml");

val ctx = FileSystemXmlApplicationContext("/conf/context.xml")

以下示例也是等效的（即使它们看起来不同也会有道理，因为一个情况是相对的，而另一个情况是绝对的）：

Java
Kotlin

FileSystemXmlApplicationContext ctx = ...;
ctx.getResource("some/resource/path/myTemplate.txt");

val ctx: FileSystemXmlApplicationContext = ...
ctx.getResource("some/resource/path/myTemplate.txt")

Java
Kotlin

FileSystemXmlApplicationContext ctx = ...;
ctx.getResource("/some/resource/path/myTemplate.txt");

val ctx: FileSystemXmlApplicationContext = ...
ctx.getResource("/some/resource/path/myTemplate.txt")

实际上，如果您需要真正的绝对文件系统路径，则应避免将绝对路径与FileSystemResource或FileSystemXmlApplicationContext一起使用，并强制使用UrlResource，方法是使用file： URL 前缀。以下示例展示了如何执行此操作：

Java
Kotlin

// actual context type doesn't matter, the Resource will always be UrlResource
ctx.getResource("file:///some/resource/path/myTemplate.txt");

// actual context type doesn't matter, the Resource will always be UrlResource
ctx.getResource("file:///some/resource/path/myTemplate.txt")

Java
Kotlin

// force this FileSystemXmlApplicationContext to load its definition via a UrlResource
ApplicationContext ctx =
	new FileSystemXmlApplicationContext("file:///conf/context.xml");

// force this FileSystemXmlApplicationContext to load its definition via a UrlResource
val ctx = FileSystemXmlApplicationContext("file:///conf/context.xml")

Resources

Introduction

The Resource Interface

Built-in Resource Implementations

UrlResource

ClassPathResource

FileSystemResource

PathResource

ServletContextResource

InputStreamResource

ByteArrayResource

The ResourceLoader Interface

The ResourcePatternResolver Interface

The ResourceLoaderAware Interface