resource是什么意思？用法、例句 Spring基础教程—资源（Resources）

大家好,今天小编来为大家解答以下的问题，关于resource是什么意思？用法、例句，Spring基础教程—资源（Resources）这个很多人还不知道，现在让我们一起来看看吧！

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

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

位于org.springframework.core.io.包中的SpringResource接口，旨在成为一个更有能力的接口，用于抽象访问低级资源。下面的列表提供了Resource接口的概述。请参阅Resourcejavadoc以了解更多细节。

publicinterfaceResourceextendsInputStreamSource{\n\nbooleanexists();\n\nbooleanisReadable();\n\nbooleanisOpen();\n\nbooleanisFile();\n\nURLgetURL()throwsIOException;\n\nURIgetURI()throwsIOException;\n\nFilegetFile()throwsIOException;\n\nReadableByteChannelreadableChannel()throwsIOException;\n\nlongcontentLength()throwsIOException;\n\nlonglastModified()throwsIOException;\n\nResourcecreateRelative(StringrelativePath)throwsIOException;\n\nStringgetFilename();\n\nStringgetDescription();\n}\n

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

publicinterfaceInputStreamSource{\n\nInputStreamgetInputStream()throwsIOException;\n}\n

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

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

Resource接口的一些实现也实现了扩展的WritableResource接口，用于支持向其写入的资源。

Spring本身也广泛地使用了Resource抽象，在许多方法签名中，当需要资源时，它是一个参数类型。一些SpringAPI中的其他方法（例如各种ApplicationContext实现的构造器）接受一个String，该字符串以未经修饰或简单的形式被用来创建适合该上下文实现的Resource，或者通过String路径上的特殊前缀，让调用者指定必须创建和使用一个特定的Resource实现。

虽然Resource接口在Spring中被大量使用，但在你自己的代码中，它作为一个普通的实用类，用于访问资源，即使你的代码不知道或不关心Spring的任何其他部分，它实际上也非常方便。虽然这将你的代码与Spring联系在一起，但它实际上只是与这一小部分实用类联系在一起，作为URL的一个更有能力的替代品，可以被认为等同于你用于此目的的任何其他库。

Resource抽象并不取代功能。它尽可能地包装它。例如，UrlResource包装了一个URL，并使用被包装的URL来完成其工作。

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

关于Spring中可用的Resource实现的完整列表，请查阅Resourceavadoc中的"所有已知的实现类"部分。

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

UrlResource是由Java代码通过明确使用UrlResource构造函数来创建的，但当你调用一个API方法时，往往是隐式创建的，该方法需要一个代表路径的String参数。对于后一种情况，JavaBeans的PropertyEditor最终决定创建哪种类型的Resource。如果路径字符串包含一个众所周知的（对属性编辑器来说）前缀（如classpath:），它将为该前缀创建一个适当的专用Resource。然而，如果它不认识这个前缀，它就假定这个字符串是一个标准的URL字符串，并创建一个UrlResource。

该类表示应从classpath获得的资源。它使用线程上下文的类加载器、一个给定的类加载器或一个给定的类来加载资源。

如果classpath资源驻留在文件系统中，该Resource实现支持作为java.io.File的解析，但对于驻留在jar中且未被扩展（由servlet引擎或任何环境）到文件系统中的classpath资源，则不支持。为了解决这个问题，各种Resource实现总是支持解析为java.net.URL。

Java代码通过明确使用ClassPathResource构造函数来创建ClassPathResource，但当你调用一个API方法时，往往会隐含地创建，该方法需要一个代表路径的String参数。对于后一种情况，JavaBeansPropertyEditor会识别字符串路径上的特殊前缀classpath:，并在这种情况下创建一个ClassPathResource。

这是一个用于java.io.File句柄的Resource实现。它也支持java.nio.file.Path句柄，应用Spring标准的基于String的路径转换，但通过java.nio.file.FilesAPI执行所有操作。对于纯粹的基于java.nio.path.Path的支持，请使用PathResource代替。FileSystemResource支持以`File`和URL的形式解析。

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

这是一个用于ServletContext资源的Resource实现，它解释了相对于Web应用根目录中的相对路径。

它总是支持流访问和URL访问，但只有当Web应用程序归档文件被扩展并且资源在文件系统上时才允许java.io.File访问。无论它是否被扩展并在文件系统上，还是直接从JAR或其他地方（如数据库）访问（这是可以想象的），实际上都取决于Servlet容器。

InputStreamResource是给定的InputStream的一个Resource实现。只有在没有特定的Resource实现的情况下才应该使用它。特别是在可能的情况下，最好选择ByteArrayResource或任何基于文件的Resource实现。

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

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

它对于从任何给定的字节数组中加载内容是很有用的，而不必求助于单一用途的InputStreamResource。

ResourceLoader接口的目的是由可以返回（也就是加载）资源实例的对象来实现。下面的列表显示了ResourceLoader接口的定义。

publicinterfaceResourceLoader{\n\nResourcegetResource(Stringlocation);\n\nClassLoadergetClassLoader();\n}\n

所有的应用applicationcontext都实现了ResourceLoader接口。因此，所有的applicationcontext都可以被用来获取Resource实例。

当你在一个特定的applicationcontext上调用getResource()，并且指定的位置路径没有特定的前缀，你会得到一个适合该特定applicationcontext的Resource类型。例如，假设下面这段代码是针对ClassPathXmlApplicationContext实例运行的。

Resourcetemplate=ctx.getResource("some/resource/path/myTemplate.txt");\n

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

因此，你可以以适合于特定applicationcontext的方式加载资源。

另一方面，你也可以通过指定特殊的classpath:前缀来强制使用ClassPathResource，而不管applicationcontext类型如何，正如下面的例子所示。

Resourcetemplate=ctx.getResource("classpath:some/resource/path/myTemplate.txt");\n

过指定任何一个标准的java.net.URL前缀来强制使用UrlResource。下面的例子使用了file和https的前缀。

Resourcetemplate=ctx.getResource("file:///some/resource/path/myTemplate.txt");\nesourcetemplate=ctx.getResource("https://myhost.com/resource/path/myTemplate.txt");\n

略。

classpath:com/myapp/config.xml

作为URL从文件系统加载。另请参见FileSystemResource注意事项.

取决于底层的`ApplicationContext'。

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

publicinterfaceResourcePatternResolverextendsResourceLoader{\n\nStringCLASSPATH_ALL_URL_PREFIX="classpath*:";\n\nResource[]getResources(StringlocationPattern)throwsIOException;\n}\n

从上面可以看出，这个接口还定义了一个特殊的classpath*:资源前缀，用于所有来自类路径的匹配资源。注意，在这种情况下，资源位置应该是一个没有占位符的路径—例如classpath*:/config/beans.xml。JAR文件或类路径中的不同目录可以包含具有相同路径和相同名称的多个文件。关于classpath*:资源前缀的通配符支持的进一步详情，请参见ApplicationContext构造器资源路径中的通配符及其子章节。

传入的ResourceLoader（例如，通过ResourceLoaderAware语义提供的资源加载器）可以被检查它是否也实现了这个扩展接口。

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

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

ResourceLoaderAware接口是一个特殊的回调接口，用于识别期望被提供ResourceLoader引用的组件。下面的列表显示了ResourceLoaderAware接口的定义。

publicinterfaceResourceLoaderAware{\n\nvoidsetResourceLoader(ResourceLoaderresourceLoader);\n}\n

当一个类实现了ResourceLoaderAware并被部署到applicationcontext中时（作为Spring管理的Bean），它被applicationcontext识别为ResourceLoaderAware。应用applicationcontext然后调用setResourceLoader(ResourceLoader)，将自己作为参数（请记住，Spring的所有applicationcontext都实现了ResourceLoader接口）。

由于ApplicationContext是一个ResourceLoader，Bean也可以实现ApplicationContextAware接口并直接使用所提供的applicationcontext来加载资源。然而，一般来说，如果你只需要使用专门的ResourceLoader接口，那会更好。代码将只与资源加载接口（可被视为一个实用接口）耦合，而不是与整个SpringApplicationContext接口耦合。

在应用程序组件中，你也可以依赖ResourceLoader的自动装配，作为实现ResourceLoaderAware接口的替代方案。传统的constructor和byType自动装配模式（如注入协作者（AutowiringCollaborators）中所述）能够分别为构造器参数或设置器方法参数提供一个ResourceLoader。为了获得更多的灵活性（包括自动装配字段和多个参数方法的能力），可以考虑使用基于注解的自动装配功能。在这种情况下，只要字段、构造函数或方法带有@Autowired注解，ResourceLoader就会被自动装配到期望有ResourceLoader类型的字段、构造函数参数或方法参数中。更多信息请参见使用@Autowired。

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

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

然后注入这些属性的琐碎之处在于，所有的应用applicationcontext都注册并使用一个特殊的JavaBeansPropertyEditor，它可以将String路径转换为Resource对象。例如，下面的MyBean类有一个Resource类型的template属性。

publicclassMyBean{\n\nprivateResourcetemplate;\n\npublicsetTemplate(Resourcetemplate){\nthis.template=template;\n}\n\n//...\n}\n

在XML配置文件中，template属性可以用该资源的一个简单字符串来配置，如下例所示。

<beanid="myBean"class="example.MyBean">\n<propertyname="template"value="some/resource/path/myTemplate.txt"/>\n</bean>

请注意，资源路径没有前缀。因此，由于applicationcontext本身将被用作ResourceLoader，所以资源将通过ClassPathResource、FileSystemResource或ServletContextResource加载，这取决于applicationcontext的具体类型。

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

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

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

如果MyBean类被重构以用于注解驱动的配置，myTemplate.txt的路径可以存储在一个名为template.path的key下—例如，在一个提供给SpringEnvironment的属性文件中（见Environment抽象）。然后，模板路径可以通过@Value注解用属性占位符来引用（见使用@Value）。Spring将以字符串的形式检索模板路径的值，一个特殊的PropertyEditor将把字符串转换为Resource对象，并注入MyBean构造函数中。下面的例子演示了如何实现这一点。

@Component\npublicclassMyBean{\n\nprivatefinalResourcetemplate;\n\npublicMyBean(@Value("${template.path}")Resourcetemplate){\nthis.template=template;\n}\n\n//...\n}\n

如果我们想支持在classpath的多个位置—?例如在classpath的多个jars中—?的同一路径下发现的多个template，我们可以使用特殊的classpath*:前缀和通配符来定义templates.pathkey为classpath*:/config/templates/*.txt。如果我们重新定义MyBean类如下，Spring将把templatepathpattern转换为一个Resource对象数组，可以注入MyBean构造函数中。

@Component\npublicclassMyBean{\n\nprivatefinalResource[]templates;\n\npublicMyBean(@Value("${templates.path}")Resource[]templates){\nthis.templates=templates;\n}\n\n//...\n}\n2.8.ApplicationContext和资源路径

本节介绍了如何用资源创建应用applicationcontext，包括与XML一起使用的快捷方式，如何使用通配符，以及其他细节。

applicationcontext构造函数（对于一个特定的applicationcontext类型）通常需要一个字符串或字符串数组作为资源的位置路径，例如构成context定义的XML文件。

当这样的位置路径没有前缀时，从该路径建立并用于加载Bean定义的特定Resource类型取决于并适合于特定的应用环境。例如，考虑下面的例子，它创建了一个ClassPathXmlApplicationContext。

ApplicationContextctx=newClassPathXmlApplicationContext("conf/appContext.xml");\n

由于使用了ClassPathResource，所以bean定义是从classpath中加载的。但是，请看下面这个例子，它创建了一个FileSystemXmlApplicationContext。

ApplicationContextctx=\nnewFileSystemXmlApplicationContext("conf/appContext.xml");\n

现在，Bean的定义是从文件系统的一个位置（在这种情况下，相对于当前工作目录）加载的。

请注意，在位置路径上使用特殊的classpath前缀或标准的URL前缀会覆盖为加载Bean定义而创建的Resource的默认类型。考虑一下下面的例子。

ApplicationContextctx=\nnewFileSystemXmlApplicationContext("classpath:conf/appContext.xml");\n

使用FileSystemXmlApplicationContext会从classpath中加载Bean定义。但是，它仍然是一个FileSystemXmlApplicationContext。如果它随后被用作ResourceLoader，任何未加前缀的路径仍被视为文件系统路径。

ClassPathXmlApplicationContext公开了一些构造函数，以方便实例化。基本的想法是，你可以只提供一个字符串数组，其中只包含XML文件本身的文件名（没有领先的路径信息），同时提供一个Class。然后ClassPathXmlApplicationContext从提供的类中导出路径信息。

com/\nexample/\nservices.xml\nrepositories.xml\nMessengerService.class

下面的例子显示了如何实例化一个ClassPathXmlApplicationContext实例，该实例由名为services.xml和repositories.xml的文件（在classpath上）中定义的bean组成。

ApplicationContextctx=newClassPathXmlApplicationContext(\nnewString[]{"services.xml","repositories.xml"},MessengerService.class);\n

有关各种构造函数的详细信息，请参见ClassPathXmlApplicationContextjavadoc。

applicationcontext构造函数值中的资源路径可以是简单的路径（如前所示），每个路径都有一个与目标Resource的一对一映射，或者，可以包含特殊的classpath*:前缀或内部Ant风格的模式（通过使用Spring的PathMatcher工具进行匹配）。后者都是有效的通配符。

这种机制的一个用途是当你需要进行组件式的应用组装时。所有的组件都可以将上下文定义片段发布到一个众所周知的位置路径上，并且，当最终的应用程序上下文使用相同的路径创建时，前缀为classpath*:，所有的组件片段都会被自动接收。

请注意，这种通配符是专门针对在applicationcontext构造器中使用资源路径的（或者当你直接使用PathMatcher实用类层次结构时），并在构造时解析。它与Resource类型本身没有关系。你不能使用classpath*:前缀来构造一个实际的Resource，一个Resources对象一次只指向一个资源。

路径（Path）位置可以包含Ant风格的pattern，如下面的例子所示。

/WEB-INF/*-context.xml\ncom/mycompany/**/applicationContext.xml\nfile:C:/some/path/*-context.xml\nclasspath:com/mycompany/**/applicationContext.xml

当路径位置包含一个Ant风格的pattern时，解析器遵循一个更复杂的程序来尝试解析通配符。它为路径产生一个Resource，直到最后一个非通配符段，并从中获得一个URL。如果这个URL不是一个jar:URL或容器特定的变体（如WebLogic中的zip:WebSphere中的wsjar，等等），则从中获取java.io.File并通过遍历文件系统来解析通配符。在jarURL的情况下，解析器要么从中获得java.net.JarURLConnection，要么手动解析jarURL，然后遍历jar文件的内容以解析通配符。

如果指定的路径已经是一个fileURL（隐含的，因为基本的ResourceLoader是一个文件系统，或者显式的），通配符被保证以完全可移植的方式工作。

如果指定的路径是classpath位置，解析器必须通过调用Classloader.getResource()获得最后的非通配符路径段URL。由于这只是路径的一个节点（而不是最后的文件），实际上没有定义（在ClassLoader的javadoc中）在这种情况下到底会返回什么样的URL。在实践中，它总是一个代表目录的java.io.File（在classpath资源解析到文件系统位置的情况下）或某种jarURL（在classpath资源解析到jar位置的情况下）。不过，在这个操作上还是有一个可移植性问题。

如果为最后一个非通配符段获得了一个jarURL，解析器必须能够从中获得java.net.JarURLConnection或手动解析jarURL，以便能够浏览jar的内容并解析通配符。这在大多数环境中确实有效，但在其他环境中却失败了，我们强烈建议在你依赖它之前，在你的特定环境中对来自jar的资源的通配符解析进行彻底测试。

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

ApplicationContextctx=\nnewClassPathXmlApplicationContext("classpath*:conf/appContext.xml");\n

这个特殊的前缀指定了所有符合给定名称的classpath资源必须被获取（在内部，这基本上是通过调用ClassLoader.getResources(…?)发生的），然后合并以形成最终的applicationcontext定义。

通配符classpath依赖于底层ClassLoader的getResources()方法。由于现在大多数应用服务器都提供自己的ClassLoader实现，行为可能会有所不同，特别是在处理jar文件时。检查classpath*是否有效的一个简单测试是使用ClassLoader从classpath上的jar中加载一个文件：getClass().getClassLoader().getResources("<someFileInsideTheJar>")。试着用具有相同名称但位于两个不同位置的文件进行这个测试—?例如，具有相同名称和相同路径但位于classpath上不同jar中的文件。如果返回的结果不合适，请检查应用服务器文档中可能影响ClassLoader行为的设置。

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

注意，classpath*:，当与Ant风格的pattern相结合时，只有在pattern开始前至少有一个根目录时才能可靠地工作，除非实际的目标文件位于文件系统中。这意味着像classpath*:*.xml这样的pattern可能不会从jar文件的根目录中检索文件，而只能从扩展目录的根目录中检索。

Spring检索classpath条目的能力源于JDK的ClassLoader.getResources()方法，它只返回空字符串的文件系统位置（表示要搜索的潜在root）。Spring也会评估URLClassLoader的运行时配置和java.class.path清单，但这并不能保证导致可移植行为。

扫描classpath包需要classpath中存在相应的目录条目。当你用Ant构建JAR时，不要激活JAR任务的files-only开关。另外，在某些环境中，classpath目录可能不会根据安全策略被暴露出来—?例如，JDK1.7.0_45及以上版本的独立应用程序（这需要在清单中设置'Trusted-Library'。见https://stackoverflow.com/questions/19394570/java-jre-7u45-breaks-classloader-getresources）。

在JDK9的模块路径（Jigsaw）上，Spring的classpath扫描一般都能如期进行。这里也强烈建议将资源放到一个专门的目录中，以避免前面提到的搜索jar文件根层的可移植性问题。

含有classpath:资源的Ant风格的pattern不保证能找到匹配的的资源，如果要搜索的root包在多个classpath位置上可用。考虑到下面这个资源位置的例子。

com/mycompany/package1/service-context.xml

现在考虑一个Ant风格的path，有人可能会用它来试图找到这个文件。

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

这样的资源可能只存在于classpath中的一个位置，但是当像前面的例子那样的路径被用来试图解析它时，解析器根据getResource("com/mycompany");返回的（第一个）URL来工作。如果这个基础包节点存在于多个ClassLoader位置，所需的资源可能不存在于找到的第一个位置。因此，在这种情况下，你应该更倾向于使用classpath*:与Ant风格相同的pattern，它可以搜索所有包含com.mycompany基础包的classpath位置：classpath*:com/mycompany/**/service-context.xml。

未附加到FileSystemApplicationContext的FileSystemResource（也就是说，当FileSystemApplicationContext不是实际的ResourceLoader时）会按照您的预期处理绝对和相对路径。相对路径是指相对于当前工作目录，而绝对路径是指相对于文件系统的root。

然而，出于向后兼容（历史）的原因，当FileSystemApplicationContext为ResourceLoader时，情况会发生变化。FileSystemApplicationContext强制所有附加的FileSystemResource实例将所有位置路径视为相对路径，无论它们是否以前导斜线开始。在实践中，这意味着以下例子是等同的。

ApplicationContextctx=\nnewFileSystemXmlApplicationContext("conf/context.xml");\n

Java

ApplicationContextctx=\nnewFileSystemXmlApplicationContext("/conf/context.xml");\n

下面的例子也是等价的（尽管它们的不同是有道理的，因为一种情况是相对的，另一种是绝对的）。

FileSystemXmlApplicationContextctx=...;\nctx.getResource("some/resource/path/myTemplate.txt");\n

Java

FileSystemXmlApplicationContextctx=...;\nctx.getResource("/some/resource/path/myTemplate.txt");\n

在实践中，如果需要真正的绝对文件系统路径，应避免使用FileSystemResource或FileSystemXmlApplicationContext的绝对路径，而是通过使用file:URL前缀强制使用UrlResource。下面的例子展示了如何做到这一点。

//actualcontexttypedoesn'tmatter,theResourcewillalwaysbeUrlResource\nctx.getResource("file:///some/resource/path/myTemplate.txt");\n

Java

//forcethisFileSystemXmlApplicationContexttoloaditsdefinitionviaaUrlResource\nApplicationContextctx=\nnewFileSystemXmlApplicationContext("file:///conf/context.xml");\n

官网：Doker多克;官方旗舰店：首页-Doker多克多克创新科技企业店-淘宝网技术人的数码品牌！！！全品优惠，期待您的支持！！！

关于resource是什么意思？用法、例句和Spring基础教程—资源（Resources）的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。