IntelliJ从现有源/外部模型导入项目的区别及异常问题咨询

底层逻辑区别 #

• Create project from existing sources
  这是IntelliJ自带的通用导入逻辑，不绑定任何外部构建工具。导入过程只会做基础目录扫描：标记源码路径、资源路径，就算检测到目录下存在Gradle、Maven的构建配置文件，也仅做普通文件识别，不会完整拉取构建工具侧的全量配置模型。
  该模式下项目的依赖解析、编译规则优先走IntelliJ内置的构建逻辑，不会和外部构建工具的配置做严格同步，哪怕后续手动关联了Gradle，IDE侧的代码索引、语法检查也不会完全复用Gradle的解析结果。
• Create project from external model
  这是专门对接第三方构建工具的导入模式，选择对应构建工具（Gradle/Maven/SBT等）后，IntelliJ会直接调用本地对应构建工具的接口，完整拉取构建工具生成的全量项目模型：包括完整传递依赖树、构建插件动态注入的配置、源码/资源路径规则、编译参数、构建任务定义等，IDE侧的依赖解析、代码索引、编译运行逻辑完全和命令行执行构建的规则对齐，不会用内置逻辑做额外的二次推断。

Gradle+Kotlin+Spring Boot项目异常的原因 #

选择from existing sources导入时出现的Spring Boot依赖无法解析、Gradle配置异常，完全是两种导入模式的逻辑差异导致的：

Spring Boot搭配Gradle的项目中，依赖版本管理、starter依赖的传递依赖规则，并不是静态写在build.gradle.kts配置文件里的，而是由org.springframework.boot、io.spring.dependency-management两个Gradle插件在项目配置阶段动态注入的，包括Kotlin编译参数、Spring Boot特殊打包逻辑也完全依赖插件生效。

现有源码导入模式不会触发Gradle的配置阶段执行，自然拿不到插件动态注入的依赖规则、版本信息，只会静态扫描配置文件里明文写的依赖声明，必然会出现部分依赖解析失败、配置不一致的问题。这种场景下就算手动调用Gradle命令能正常构建、启动项目，IDE侧的代码索引、依赖检查用的还是自身扫描出的残缺配置，就会出现“项目能跑但依赖报红、配置异常找不到根源”的现象。
对于Gradle、Maven这类标准化构建工具管理的项目，始终优先选择from external model模式导入，才能保证IDE行为和本地命令行构建行为完全一致。

内容的提问来源于stack exchange，提问作者Emely h