我太懂这种折腾半天却卡壳的憋屈感了——多模块Maven项目导入STS确实容易踩各种隐形坑，尤其是全新安装的环境。结合你已经试过的操作，我给你整理几个针对性的排查和解决办法：

• 先清空STS的工作空间缓存
  全新安装的STS偶尔也会残留初始化的缓存垃圾，导致项目识别异常：
  1. 彻底关闭STS，找到当前工作空间的目录，删除里面的.metadata文件夹（注意：如果工作空间里还有其他重要项目，先备份再删！）
  2. 重新启动STS，选择一个全新的空白工作空间，再尝试导入项目
• 核对Maven配置是否匹配本地环境
  STS自带的嵌入式Maven经常和本地用的版本/配置不一致，这是常见的问题根源：
  • 打开STS的Window > Preferences > Maven > Installations，点击Add添加你本地正在使用的Maven版本，然后把它设为默认（别用STS自带的那个）
  • 切换到Maven > User Settings，确认User Settings路径指向你本地的settings.xml——如果你的项目依赖私服或者镜像，这个配置错了直接导致依赖拉取不到
• 调整导入时的关键选项
  用Existing Maven Projects导入时，这几个细节别忽略：
  • 选择根目录时，必须选包含父pom.xml的那个文件夹，绝对不能选子模块的单独目录
  • 确认导入窗口里的Search for nested projects是勾选状态（STS 3.9.4默认应该勾着，但最好手动确认）
  • 暂时取消勾选Add project to working set，这个选项有时候会干扰多模块的识别逻辑
• 手动修复模块依赖关联
  如果导入后项目还是飘红或者依赖报错：
  • 右键父项目，选择Maven > Update Project，勾选Force Update of Snapshots/Releases，然后点击OK强制更新依赖
  • 逐个检查子模块的pom.xml，确认父模块的groupId、artifactId、version和父pom里的内容完全一致，别出现拼写错误或者版本号不匹配
• 验证Git克隆的项目完整性
  虽然是命令行克隆，但网络波动可能导致部分文件缺失：
  • 进入项目根目录，执行git status确认有没有未拉取的文件；如果项目包含Git子模块，再执行git submodule update --init --recursive拉取所有子模块内容
  • 先在命令行执行mvn clean install -DskipTests编译项目，如果命令行能成功构建，说明项目本身没问题，问题肯定出在STS的配置上

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