目录结构
项目设置
项目
- 项目名称 ：
一般会将此处的项目名与项目目录名和pom文件中的name三处保持一致。避免不一致，同时也避免IDEA在左侧会显示多个名称标识。
如果打开的是一组项目，比如都说springboot的项目，此处本人会改为类似springboot-all这样的名称，而不是其中一个（默认是第一个）项目的名称。
- SDK ：
配置项目的SDK使用，这项平时使用的比较多，比如新打开一个项目，要查看一下SDK版本是否与预期的一致。也可以在右边的Edit进行SDK的编辑。
- 语言级别 ：选择要支持的Java语言级别。选定的级别将被用作项目默认值。如果是多个Module（可以理解为一组项目）的话，对所有Module生效。
不同的JDK版本选择，对代码的语法有一定的影响，比如选择JDK8以前的版本，那么代码中有基于Lambda的语法将会报错。目前使用最多的当属JDK8了，当然如果你的项目比较古老或比较新，也可以选择其他的版本。
可用选项对应于JDK版本：
1.3 - 普通的旧Java
1.4 - “断言”关键字
5.0 - 'enum’关键字，自动装箱等
6.0 - @Override在接口
7.0 - 钻石，ARM，多捕获等
8.0 - Lambda支持，类型注释等
可以为您的任何模块设置单独的语言级别 。
请注意，如果目标级别没有明确定义（编译器选项-target），则认为它与源语言级别相同。
因此，如果-target没有明确定义，它将与语言水平同步。
- 编译器输出 ：
指定IntelliJ IDEA将存储编译结果的路径。单击选择路径对话框中browseButton 的目录。
指定目录中的两个子目录将被创建：
production 为生产代码。
test 为测试来源。
在这些子目录中，将为每个模块创建单独的输出目录。输出路径可以在模块级重新定义。
针对单个项目，可以在配置一个输出路径，同时也可以在后面提到的Module中进行独立配置。
但对于多个Module项目时，会出现大家共用一个output目录。此时如果输出的日志文件路径用“./log”这种形式时，日志可能并不会打印到其中的子项目中，而是输出在此处指定的路径下了。
- FAQ ：
1.为何是SDK版本而不是JDK版本？答：因为IntelliJ IDEA是JVM平台IDEA，不仅仅支持Java还有其它语言如Kotlin，所以写成SDK更抽象
2.为何指定了SDK还要指定语言等级？答：因为SDK版本并不直接决定语言等级。如你用的JDK 11，但依旧可以把语言等级调为8来进行编译/运行。这是集成开发环境的优势所在，轻松对多环境进行定制化支持
3.SDK和语言等级Project都可指定，作为全局默认
这些配置Module默认集成，但可自行修改自己的。比如module 1使用Java 5编译，module 2使用Java 11编译，这是允许的
模块
Modules中的配置用的比较多的情况就是一组项目时，可以配置独立每个项目的参数。包括项目名称，目录结构，输出路径，依赖等。Module作为实际存在形式，所有的源代码、配置、依赖等都在这里，因此大有可学
源
值得注意：Tests测试包里面的是可以访问Sources源码的，但反过来不行。
加号可以导入、新增各类Module项目，当然后面的减号可以移除对应的项目
Sources：源代码存放的文件，蓝色。
Tests：设置测试代码存放的文件件，绿色。
Resources：一般对应着Sources文件，一般放配置文件，如：log4j.properties，application.yml。
Test Resources：这个对应着Tests文件夹，存放着Tests代码的配置文件。
Excluded：设置配出编译检查的文件，例如我们在project模块设置的out文件夹。
路径
依赖
管理这个module的依赖项，依赖项可能是library包，也可能是其它的module。这里有个export选项，这个选项被选上了话，那么说明：将来某一个module依赖本module的话，那么被选中这个选项的项也会出现在那个module中。也就是说，有一个传递性
每个模块都能独立管理着自己的依赖，这种关系在模块自己的{moduleName}.iml文件中记录着。
Project创建时默认会创建一个同名的Module模块
- Maven的编译范围，默认为编译
- 编译 ：对项目类和测试类来说，编译和运行都有效
- 测试 ：仅对测试类来说，编译和运行都有效
- 运行时 ：对项目类和测试类来说，仅运行时有效
- 已提供 ：对项目类来说，仅编译时有效；对测试类来说，构建和运行时有效
增加了新的依赖后，对应的iml文件也会发生变化
新建Java依赖库
这种方式简单的讲：从你本机里选择一个jar（或者一个目录里面包含jar、文档）就成。优点是非常轻便，不依赖网络，缺点是这些jar必须是你本机已实际存在的。
注意范围是模块级别，不是project级别！
新建Maven依赖库
输入GAV（或者关键字查找）就能定位到jar，此种方式使用起来其实非常方便，毕竟maven非常好用嘛。缺点自然就是一般情况下需要都需要依赖于网络喽，除非你本地仓库已存在对应的jar。
依赖作用范围
在New Library创建依赖的时候，不管用哪种方式选中后，它都会弹出这个窗口让你选择此依赖的作用范围
Module Library：模块级别，只能本模块使用，别的模块看都看不见
Project Library（默认选中）：项目级别，该项目下所有的模块均能看见和选中使用
Global Library：全局级别，任何项目均可看见和使用
库
当某Library是所有/大部分模块都需要的依赖时，就可以上升为Project级别的依赖，抽取到Libraries标签页来统一管理。如图，因为上面步骤创建的commons-lang3是项目级别的，所以也会出现在这里。
至于如何创建/添加Project级别的依赖，这里就不用再赘述了吧，上面【新增依赖】章节已讲得很明白。唯一区别在该页面选好后不用再选择Library的作用范围了（因为就是Project级别的嘛），取而代之的是让你选择作用的模块：
当然喽，你也可以一个都不选（点击cancle），那么该jar只是被创建了，而不作用于任何module模块。
说明：对于一个多模块的Project来讲，建议项目使用的所有Jar都放在这里统一管理，模块要使用时直接按需choose就成，而不需要自己再单独add，方便统一管理
Facet
表示这个 module 有什么特征，比如 Web，Spring 和 Hibernate 等；
Facets可理解为用于配置Project项目的框架区，它能看到项目的每个Module模块使用的框架、语言等情况，并且还可以对它们进行配置。
比如Spring框架，如果某个模块使用了它就可以来这里统一配置。优点是你会发现借助IDEA强大的功能它都给你想好了哪些地方可配置，你可以更改，让你实现配置界面化。除了Spring，其它框架如Hibernate也是如此~
目前支持的Facets（语言/框架）类型有：
说明：不同的Facet对应的最右端窗口内容配置项是不一样的。
通过此视窗，可以看到你当前Project项目，哪些模块使用了Spring框架，哪些是web项目，一目了然。它有个非常大的作用就是站在Project的视角对每个模块进行整体把控，比如若你发现有个模块不需要是web项目（并不需要对外提供服务接口），那铁定就是多引包了或者职责不清晰导致的，就可立马针对性解决，消除隐患。
在实际工作中我自己比较频繁的使用这个功能，用于对模块性质的定位，比如如果是普通模块，绝对不允许是web工程，如果不需要依赖Spring绝对不允许成为Spring工程。因为严格控制Jar包依赖、工程性质是应对大型项目的有效手段。
当然喽，Facets还有个作用是让IDEA编译器认识你的模块，比如如果你是个web模块，若没有在Facets里体现出来，那IDEA就不认识你，就无法给你提供web的一些便捷操作了。
工件
Artifact 是 maven 中的一个概念，表示某个 module 要如何打包，例如 war exploded、war、jar、ear 等等这种打包形式；
一个 module 有了 Artifacts 就可以部署到应用服务器（比如tomcat）中了！
Artifacts这个概念不是特别好理解，artifact是maven里的一个概念，被IDEA借鉴过来。表示某个模块要何种打包形式，如jar、war exploded、war、ear等等。Artifact是一个项目资源的组合体，整合编译后的 java 文件，资源文件等。有不同的整合方式，比如jar、war、war exploded等等，对于一个module而言，有了Artifact就可以部署了，类似于maven的package打包。
说明：war 和 war exploded区别就是后者不压缩，开发时选后者便于实时看到修改文件后的效果
jar：Java ARchive，通常用于聚合大量的Java类文件、相关的元数据和资源（文本、图片等）文件到一个文件，以便分发Java平台应用软件或库；
war：Web application ARchive，一种JAR文件，其中包含用来分发的JSP、Java Servlet、Java类、XML文件、标签库、静态网页（HTML和相关文件），以及构成Web应用程序的其他资源；
exploded：展开，不压缩的意思。也就是war、jar等产出物没压缩前的目录结构。建议在开发的时候使用这种模式，便于修改了文件的效果立刻显现出来。
来个栗子，这里演示下将hello模块打包成一个Jar：
配置好后，只需顶部菜单栏Build -> Build Artifacts，就可以打出这个Jar包：
执行完此命令后，在Output Directory里就能看到hello.jar这个打包好的文件啦。然后java -jar .\hello.jar就能运行喽（因为咱们打的是可执行Jar包）。关于使用IDEA打包还包括打可执行jar包、Fatjar、包外引用jar包等等
当你点击运行tomcat时，默认就开始做以下事情：
编译，IDEA在保存/自动保存后不会做编译，不像Eclipse的保存即编译，因此在运行server前会做一次编译。编译后class文件存放在指定的项目编译输出目录下（2.2）
根据artifact中的设定对目录结构进行创建；
拷贝web资源的根目录下的所有文件到artifact的目录下（2.3）
拷贝编译输出目录下的classes目录到artifact下的WEB-INF下（2.2）
拷贝lib目录下所需的jar包到artifact下的WEB_INF下；
运行server，运行成功后，如有需要，会自动打开浏览器访问指定url。
在这里还要注意的是，配置完成的artifact，需要在tomcat中进行添加部署
模块如何依赖其它Module
一个中大型项目一般有多个模块，它们各司其职。模块与模块之间一般都存在依赖关系，比如常见的xxx-core模块一般会被其它几乎所有模块所依赖。模块依赖外部库Library知道怎么搞了，那么如何增加本项目的模块依赖呢？
其实道理和步骤基本一样，比如hello-core模块里有个Person类：
hello-service模块也需要用到Person类及其功能，那么就需要把hello-core模块依赖进来，操作步骤如下：
添加Dependency依赖时，请选择Module Dependency…选项：
选择本项目中需要依赖进来的模块：
选中hello-core模块把它依赖到hello-service里来：
点击ok，搞定了。对应的，此依赖关系也会体现在hello-service.iml这个配置文件上：
如此，我们就可以在hello-service模块里正常使用Person类啦：
public static void main(String[] args) {
System.out.println(new Person());
}平台设置/全局设置
用于管理SDK们（如JDK、Kotlin的SDK等）、全局库。
一般来讲，全局的JDK都会配置在此处，比如我因为经常要做多版本尝试，就管理了多个JDK版本
SDK
全局类库
问题
一般项目出现了问题都会在此体现（如依赖不一致问题等等），总之问题数量一致让它是0是最优的
