来自官方JAR文件规范(链接到Java 7版本，但文本至少从v1.3开始就没有改变):

The META-INF directory The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services: MANIFEST.MF The manifest file that is used to define extension and package related data. INDEX.LIST This file is generated by the new "-i" option of the jar tool, which contains location information for packages defined in an application or extension. It is part of the JarIndex implementation and used by class loaders to speed up their class loading process. x.SF The signature file for the JAR file. 'x' stands for the base file name. x.DSA The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file. services/ This directory stores all the service provider configuration files.

自Java 9实现JEP 238以来新增了多版本jar。一个会看到子文件夹的版本。这个特性允许将不同Java版本的类打包到一个jar中。

META-INF文件夹是清单的主页。MF文件。该文件包含关于JAR内容的元数据。例如，有一个名为main - class的条目，它为可执行JAR文件指定了带有静态main()的Java类的名称。

一般来说，您自己不应该在META-INF中放入任何东西。相反，您应该依赖于您用来打包JAR的任何东西。这是我认为Ant真正擅长的领域之一:指定JAR文件清单属性。这样说很容易:

<jar ...>
    <manifest>
        <attribute name="Main-Class" value="MyApplication"/>
    </manifest>
</jar>

至少，我认为这很简单……: -)

关键是meta - inf应该被视为一个内部Java元目录。别乱动它!您希望包含在JAR中的任何文件都应该放在其他子目录中或JAR本身的根目录中。

我注意到一些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中，到底有什么问题。但这似乎是一个新兴的事实标准;要么这样，要么出现反模式:-)

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

如果您使用的是JPA1，则可能必须在其中放入一个persistence.xml文件，该文件指定您可能想要使用的持久化单元的名称。持久化单元提供了一种方便的方式，可以指定一组元数据文件、类和包含分组中要持久化的所有类的jar。

import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

点击这里查看更多信息: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

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

为什么会这样呢?

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

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

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

你也可以在那里放置静态资源。

在示例:

META-INF/resources/button.jpg 

并通过web3.0容器获取它们

http://localhost/myapp/button.jpg

>阅读更多

/ meta - inf / MANIFEST。MF有特殊的含义:

如果你使用java -jar myjar.jar org.myserver.MyMainClass运行一个jar，你可以将主类定义移动到jar中，这样你就可以将调用缩小到java -jar myjar.jar。 如果你使用java.lang.Package.getPackage("org.myserver"). getimplementationtitle()，你可以为包定义元结构。 您可以在Applet/Webstart模式中引用您喜欢的数字证书。

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项目添加资源。

所有答案都是正确的。Meta-inf有很多用途。此外，这里还有一个关于使用tomcat容器的示例。

去 Tomcat Doc并检查 “标准实现> copyXML”属性。

描述如下。

Set to true if you want a context XML descriptor embedded inside the application (located at /META-INF/context.xml) to be copied to the owning Host's xmlBase when the application is deployed. On subsequent starts, the copied context XML descriptor will be used in preference to any context XML descriptor embedded inside the application even if the descriptor embedded inside the application is more recent. The flag's value defaults to false. Note if the deployXML attribute of the owning Host is false or if the copyXML attribute of the owning Host is true, this attribute will have no effect.

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

例子:

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

来源:Head First Jsp & Servlet

添加到这里的信息，META-INF是一个特殊的文件夹，ClassLoader将其与jar中的其他文件夹区别对待。 嵌套在META-INF文件夹内的元素不会与它外部的元素混合。

把它想象成另一个根。从Enumerator<URL> ClassLoader#getSystemResources(字符串路径)方法等透视图:

当给定的路径以“META-INF”开头时，该方法搜索类路径中所有jar的META-INF文件夹内嵌套的资源。

当给定的路径不是以“META-INF”开头时，该方法在类路径中所有jar和目录的所有其他文件夹(在META-INF之外)中搜索资源。

如果您知道getSystemResources方法特别处理的另一个文件夹名称，请对其进行评论。

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.