只是在这里添加信息，如果是WAR文件，则是META-INF/MANIFEST。MF文件为开发人员提供了由容器发起部署时检查的工具，以确保容器可以找到应用程序所依赖的所有类。这确保了万一您丢失了一个JAR，您不必等到应用程序在运行时崩溃时才意识到它丢失了。

Maven中的META-INF

在Maven中，META-INF文件夹被理解是因为标准目录布局，根据名称约定将您的项目资源打包到JAR中:放置在${basedir}/src/main/resources目录中的任何目录或文件都以完全相同的结构打包到JAR中，从JAR的底部开始。

文件夹${basedir}/src/main/resources/META-INF通常包含。properties文件，而在jar中包含一个生成的MANIFEST。MF,砰的一声。属性，pom.xml，以及其他文件。同样，像Spring这样的框架使用classpath:/META-INF/resources/来提供web资源。

有关更多信息，请参阅如何向Maven项目添加资源。

我注意到一些Java库已经开始使用META-INF作为目录，其中包含应该打包并与jar一起包含在CLASSPATH中的配置文件。例如，Spring允许您使用以下方法导入类路径上的XML文件:

<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />

在本例中，我直接引用Apache CXF用户指南中的内容。在我参与的一个项目中，我们必须允许通过Spring进行多级配置，我们遵循了这个约定，并将配置文件放在META-INF中。

当我反思这个决定时，我不知道简单地将配置文件包括在特定的Java包中，而不是在META-INF中，到底有什么问题。但这似乎是一个新兴的事实标准;要么这样，要么出现反模式:-)

你有舱单。MF文件在你的META-INF文件夹。您可以定义必须访问的可选或外部依赖项。

例子:

假设你已经部署了你的应用程序，你的容器(在运行时)发现你的应用程序需要一个不在lib文件夹内的库的新版本，在这种情况下，如果你在MANIFEST中定义了可选的新版本。MF，那么你的应用程序将从那里引用依赖(不会崩溃)。

来源:Head First Jsp & Servlet

As an addition the META-INF folder is now also used for multi-release jars. This is a feature which allows to package classes which are meant for different Java version in one jar, e.g. include a class for Java 11 with new features offered by Java 11 in a jar also working for Java 8, where a different class for Java 8 with less features in contained. E.g this can be useful if a newer Java version is offering enhanced, different or new API methods which would not work in earlier version due to API violations. One will see a sub folder versions then.

我最近一直在思考这个问题。对于META-INF的使用似乎真的没有任何限制。当然，有一些限制，关于把舱单放在那里的必要性，但似乎没有任何禁止把其他东西放在那里。

为什么会这样呢?

cxf案例可能是合法的。这里是建议使用非标准的另一个地方，它可以绕过JBoss-ws中防止针对wsdl模式进行服务器端验证的严重错误。

http://community.jboss.org/message/570377#570377

但似乎真的没有什么标准，没有什么千言万语。通常这些事情都有非常严格的定义，但出于某种原因，这里似乎没有标准。奇数。META-INF似乎已经成为了一个无所不包的地方，任何所需的配置都无法通过其他方式轻松处理。