★ FEATURED ARTICLE 一上来就报Plugin org.springframework.boot:spring-boot-maven-plugin not found这应该是不少 Spring Boot 开发者在 Maven 打包、IDEA 构建时最眼熟的报错之一。单看错误信息Maven 好像是在说“我找不到这个插件”但实际落地排查时你会发现问题可能出在 Maven 版本、镜像仓库、本地仓库缓存、IDEA 内置 Maven 配置、父 POM 的插件管理甚至 Docker 构建环境里。这篇内容我会把这个报错从现象到根因、从解决到避坑完整过一遍写给刚碰到这个问题的新手也给需要快速定位的老手一份排查手册。我直接把最近实测可用的方案放在前面如果你只想快点让项目跑起来先看 1.1 和 2.1如果你想弄明白为什么会出现not found后面所有的章节都是围绕这个展开的。1. 这个报错到底在说什么1.1 快速解决先给插件补上明确的版本号大部分项目只要在根 POM 的buildplugins里加上版本号也就是把version写出来问题立刻消失plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version2.7.18/version /plugin很多教程和脚手架默认不写version因为 Spring Boot 的父 POMspring-boot-starter-parent已经帮你托管了版本。但你的项目如果父 POM 不是它或者父依赖管不到这个插件Maven 找不到可用的版本号就会直接报not found。没有版本号的插件声明对 Maven 来说等于“无效配置”它会尝试查一个不存在的版本最终在本地仓库和远程仓库都拿不到匹配项于是抛出这个错误。补全版本之后建议顺手执行一次mvn clean package不要只刷新 IDEA因为本地仓库里可能已经有损坏的下载残留命令行重新走一遍下载流程最稳妥。1.2 先判断你自己的场景属于哪一种我梳理了最常见的三类报错现场你可以直接对号入座场景核心特征最可能原因新建项目直接打包在 IDEA 里点 maven package首次构建还没看到任何项目依赖下载Maven 默认仓库无法解析插件元数据或没写版本号老项目突然报错之前还能打包换电脑或换 IDEA 之后就报错本地 Maven 配置指向新仓库或换了 Maven 版本Docker 多阶段构建报错镜像里跑 Maven 构建时找不到插件镜像内 Maven 与宿主机配置不同无法访问外网或私有仓库这三个场景虽然报错相同但我不会把三个场景割裂开讲因为底层还是同一个问题Maven 在编译插件和解析插件时走的是和依赖解析完全不同的流程。区别只在于哪些配置项会影响某个场景。2. 报错背后的 Maven 插件解析原理2.1 Maven 是如何去找一个插件的Maven 解析插件和解析普通依赖走的不是同一条路径。普通依赖会去repositories配置的仓库地址拉取而 Maven 自带插件、第三方插件的解析使用的是pluginRepositories。Spring Boot 的spring-boot-maven-plugin是第三方插件默认会去 Maven Central 找。这里有一个容易忽略的坑如果你在 settings.xml 里配了阿里的mirror早期版本的镜像节点会把所有仓库请求都重定向到阿里云仓库这不一定会出问题但如果你的私服或自定义源没有把 Spring Boot 插件元数据同步完整就会导致插件前缀解析失败。Maven 找插件时会先解析插件前缀。所谓前缀就是你写命令时用的spring-boot:run里的spring-bootMaven 会把org.springframework.boot这个 groupId 和spring-boot-maven-plugin这个 artifactId 对应起来。这个映射关系不是硬编码在 Maven 里的它依赖插件仓库下的maven-metadata.xml。如果本地仓库中这个 XML 文件不存在或者远程仓库返回的 XML 里没有对应版本Maven 就会告诉你not found。我实测过一种很典型的情况项目里配置了私有 Nexus 仓库但pluginRepositories没有配置导致依赖 jar 能正常从私服下载插件却一直报 not found。因为私服上确实放了 Spring Boot 插件但 Maven 根本就不会去私服问插件它只会去默认的 Central 问。此时私服策略如果没做“Central 代理合并”插件解析失败就是必然的。2.2 版本号到底去哪儿了Spring Boot 项目中不写插件版本依赖的是父 POMparent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent父 POM 的pluginManagement里会声明插件的版本所以子模块里只写 groupId 和 artifactId 就行。但以下几个坑会让继承失效父 POM 不是spring-boot-starter-parent是公司内部的company-parent它本身没有继承 Spring Boot 父 POM。子模块没有写parent独立成一个孤儿模块。父 POM 设置了relativePath指向了一个不存在的本地 pom 文件IDEA 或命令行解析父 POM 失败插件版本随之丢失。项目使用了spring-boot-dependencies的 BOM 方式管理依赖但 BOM 里的spring-boot-maven-plugin版本没有通过pluginManagement引入只是用 dependencyManagement 引入了插件依然缺版本。我见过最多的就是第二种和第四种。单体项目还好一旦拆了多模块把插件声明放在子模块父 POM 只在一个modules里列了子模块没有做任何版本管理那么这个插件铁定找不到版本。你在 IDEA 里能正常刷新依赖只是因为 IDEA 对插件缺失的容忍度更高到命令行打包时就原形毕露了。2.3 本地仓库里的“幽灵文件”也能造成 not foundMaven 下载任何依赖和插件都会先落在~/.m2/repository。如果之前因为网络中断、磁盘满了、IDEA 强制停止等原因导致插件目录里只残留了几个不完整的lastUpdated文件和半截 jarMaven 会认为这个插件已经存在不再重新下载。这种残留文件有很明显的特征你检查~/.m2/repository/org/springframework/boot/spring-boot-maven-plugin/2.7.18/目录发现里面有.lastUpdated后缀的文件相关的 pom 和 jar 大小异常比如只有几百字节。这种情况下无论你改多少配置都无济于事因为 Maven 压根没打算再去远程问一遍。解决方式就是强制更新或者直接手动删目录mvn clean package -U-U参数的意思是强制更新快照和插件元数据能解决一部分lastUpdated问题。如果-U没效果就把整个org/springframework/boot/spring-boot-maven-plugin目录删掉然后重新构建让 Maven 重新拉取。这里也顺带提醒一句本地仓库属于“越用越乱”的典型新环境首次构建时的报错概率远高于构建过三次以上的环境。如果删目录后仍报错直接把~/.m2/repository下.lastUpdated文件全局清理一遍再配合-U执行能解决绝大多数“看似配置问题”的插件解析故障。3. 完整排查手册从环境配置到项目结构3.1 第一步确认 Maven 用的是哪份 settings.xml这句话看起来像废话但恰恰是很多人栽跟头的地方。尤其是 Windows 上系统里可能装着一个 3.6.3 的 MavenIDEA 又自行下载了一个 3.9.6 的 Maven两者加载的 settings.xml 完全不是同一个。命令行mvn -v看到的是一个版本IDEA 里 Settings 里看到的是另一个版本。命令行里 mirror 走阿里云IDEA 里 mirror 走默认中央仓库。命令行里配置了公司私服IDEA 里用的是默认官方仓库。插件 not found 是否是某一方配置里的pluginRepositories缺失所导致需要分别验证。最快的方式是打开命令行执行一次构建比如mvn clean package -DskipTests如果命令行能正常打包IDEA 里报 not found基本就是两处 Maven 配置不统一。IDEA 的配置在Settings - Build, Execution, Deployment - Build Tools - Maven你要确认Maven home path指向哪个 Maven。User settings file是否勾选了 Override。Local repository是否同步对应。我建议无论 Windows 还是 Linux都以一份 settings.xml 为准。统一放到~/.m2/settings.xml这种默认位置然后命令行和 IDEA 都用默认加载不要搞特殊 override后续维护成本最低。3.2 第二步用两个命令定位插件解析路径这里给你一个非常高效的定位组合先执行mvn help:effective-settings再执行mvn help:effective-pom。effective-settings会输出当前 Maven 进程实际生效的 settings 内容包括 mirror、profile、pluginRepositories 全部展开。我见过很多“我以为配了实际没生效”的 case都是因为 profile 的 activation 条件不满足或者 settings 文件没在标准路径。mvn help:effective-settings -Doutput/tmp/effective-settings.xml打开生成的 XML 直接搜pluginRepositories常规情况下应该能搜到central。如果你配了秋田私服、阿里云公共仓库等这里都应该有对应的仓库地址。help:effective-pom则更直接它会展示当前项目最终解析的完整 POM 内容包括父 POM 继承的所有内容。搜索spring-boot-maven-plugin如果搜出来只有 groupId 和 artifactId没有 version就说明版本继承没有生效如果搜都搜不到说明这个插件声明根本没有被解析到。这两个命令的组合足以区分问题在“配置环境”还是“项目结构”。3.3 第三步检查项目结构里的插件声明位置不同位置声明插件影响范围不同。我把常见的几种写法放到一张表里声明位置影响范围推荐程度根 POMbuildplugins当前项目及其聚合模块单体项目推荐根 POMbuildpluginManagement统一管理但不直接执行子模块按需声明多模块项目推荐子模块buildplugins只有该子模块生效模块独立打包时推荐子模块使用${revision}版本配合 CI 变量或父 POM 属性新手慎用如果你是在多模块项目里排查尽量把插件版本放到pluginManagement中管理这样后续升级 Spring Boot 版本时只需改一处。Spring Boot 父 POM 本身就是这么做的你继承了它就相当于拿到了整个插件版本管理表。如果因为特殊原因无法继承自己在根 POM 复制一份同样的做法是最稳妥的。我还见过一种脏场景根 POM 的plugins和pluginManagement里都声明了同名插件但版本不一致。Maven 对pluginManagement的处理是“仅做默认值”一旦plugins里写了不同的 version就会覆盖pluginManagement里的值。排查时需要注意多个地方都写了插件的情况不要只搜到一处就下结论。3.4 第四步区分“无法下载”与“下载后无法解析”这个问题很容易踩误区not found 不等于连不上网络。如果你能看到日志里出现类似Could not transfer artifact、Connection timed out、PKIX path building failed那就是网络或证书问题和插件本身无关。真正的 not found 往往发生在 Maven 已经连接上仓库但仓库返回中没有对应版本。你可以手动打开浏览器进入 Maven Central 的搜索页搜spring-boot-maven-plugin。如果你配置的是阿里云的公共仓库就直接访问阿里云的仓库路径比如https://maven.aliyun.com/repository/public/org/springframework/boot/spring-boot-maven-plugin/maven-metadata.xml这个maven-metadata.xml只要能在浏览器里打开并且能看到版本列表那么远程仓库的pluginRepositories配置大概率是正常的。如果打不开或者打开后里面没有你需要的版本问题就变成“这个仓库可用性不足”那就该考虑换仓库或者加仓库而不是在项目里死磕。这里也有一个基础但必须说透的点Maven 插件仓库和依赖仓库完全可以不一致因此你在依赖里能下到 Spring Boot 的 jar不代表插件也能下到。这也是为什么 settings.xml 里同时要维护repositories和pluginRepositories的原因。3.5 第五步Docker 构建场景独立排查现在很多项目都用 Docker 多阶段构建例如FROM maven:3.8-openjdk-11 AS build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests在这种场景下报 not found重点检查两个地方第一基础镜像里的 Maven 自带一份~/.m2/settings.xml它默认指向 Maven Central。如果你的项目依赖的是内网私服镜像内根本没有私服地址配置那么插件解析会直接失败。第二多阶段构建中COPY pom.xml .只拷贝了根 POM没有拷贝子模块的 POM 文件。如果这是一个多模块项目Maven 会拿着根 POM 去找子模块 POM找不到就可能影响整个构建流程。最直接的解决办法是在 Dockerfile 里手动复制 settings.xmlCOPY settings.xml /root/.m2/settings.xml同时注意如果你用maven:3.8-openjdk-11这类官方镜像镜像内默认用户是 root/root/.m2是它的本地仓库目录。如果你通过--user切换了运行时用户仓库路径就要跟着变。我遇到过更隐蔽的情况镜像里 Maven 能解析插件但构建到一半下载依赖时卡死因为官方镜像时区、DNS 配置与宿主机不同导致访问公司私服时证书校验失败。配合-Dmaven.wagon.http.ssl.insecuretrue可以绕过证书校验加快排查但这只适合临时排查不建议用在正式 Dockerfile 里。4. 常见问题排查实录与避坑指南4.1 不同报错症状对应的问题清单我顺手整理了一个排查速查表基本覆盖了实际接触过的各种变体。你可以直接按行对照症状排查点解决方向新项目第一次打包就报 not found插件声明没有 version父 POM 未继承补版本或继承 spring-boot-starter-parent报错指向某个具体版本例如 2.7.18 not found远程仓库元数据里没有该版本检查 Maven Central / 私服同步状态mvn -U强制刷新本地仓库有插件目录但报 not found目录内只剩 .lastUpdated 等残缺文件删掉对应目录重新拉取命令行正常IDEA 报错Maven 配置不一致统一 IDEA 与命令行的 Maven home、settings.xml、local repositoryDocker 构建时 not found镜像内 Maven 无法访问远程仓库/私服复制 settings.xml 到镜像确认 HTTP 代理和私有证书多模块项目部分模块报错子模块插件声明没走父 POM 的 pluginManagement在子模块补 version 或修正 parent 继承内网环境无法下载任何插件完全没有网或仓库地址只允许内网访问预先下载插件到本地仓库或使用私服中转修改配置后仍不生效IDEA 缓存或 Maven 缓存重启 IDEA删除本地仓库相关插件目录4.2 内网环境离线安装插件的完整过程如果你所在环境完全无法访问外网靠 Maven 自动下载是不可能成功的。这时可以把插件手动塞进本地仓库。步骤不复杂我演示一次。先准备一个能访问外网的机器或者从公司内部已有的制品库下载这两个文件spring-boot-maven-plugin-2.7.18.jarspring-boot-maven-plugin-2.7.18.pom然后在离线机器的本地仓库中按路径放置~/.m2/repository/org/springframework/boot/spring-boot-maven-plugin/2.7.18/ ├── spring-boot-maven-plugin-2.7.18.jar ├── spring-boot-maven-plugin-2.7.18.pom └── spring-boot-maven-plugin-2.7.18.jar.sha1如果没有 sha1 文件可以先尝试直接打包Maven 有时能接受缺失校验文件如果它要求必须校验就用工具生成对应哈希值放进去。另一个更规范的方法是直接拷贝完整仓库目录把在线环境里的~/.m2/repository/org/springframework/boot/spring-boot-maven-plugin整个压缩传到离线机器后解压到同路径。这个方法不会漏掉maven-metadata-central.xml等元数据文件插件前缀解析成功率更高。还有一点必须提醒离线安装了插件 jar 之后项目里如果同时使用spring-boot:run这样带前缀的命令本地仓库还需要存在对应的maven-metadata-central.xml。没有这份元数据即使 jar 已经在仓库里Maven 依然可能报插件前缀找不到。我遇到过一模一样的场景——插件 jar 已经就位直接写全限定坐标可以执行但spring-boot:run仍然报 not found原因就是元数据缺失。4.3 插件版本与 Spring Boot 版本不匹配的坑不要觉得不写版本就不会有兼容性问题。当你继承了spring-boot-starter-parent时插件版本跟 Boot 版本是绑定的当你手动指定 version 时就要保证插件版本与当前 Spring Boot 版本兼容。从个人经验看Spring Boot 2.x 的插件版本一般都是 2.x 系列高位版本可以向下兼容大部分 2.x 应用但如果你在 Spring Boot 3.x 项目里用了 2.7.18 的插件很可能出现 repackage 失败、Main-Class 没有被正确写入等问题。插件 not found 的问题是解决了新的问题又冒出来所以版本对齐这件事要在第一步就做好。推荐做法优先使用父 POM 托管的版本不写死。只有在父 POM 没有提供版本时才显式指定并且指定为当前 Spring Boot 配套插件版本。举例来说Spring Boot 3.2.1 对应spring-boot-maven-plugin3.2.1Spring Boot 2.7.18 对应 2.7.18版本号和 Boot 版本保持一致是最不易出错的。4.4 本地仓库全局清理与安全操作很多人一遇到插件问题就直接把整个~/.m2/repository删掉。这招确实有效但代价极大重新下载几百个依赖 jar耗时几个小时都是常事。更好的思路是精准删除。我常用的两个方式方式一Windows 命令行里进入本地仓库目录删除所有.lastUpdatedGet-ChildItem -Path $env:USERPROFILE\.m2\repository -Filter *.lastUpdated -Recurse | Remove-Item -Force方式二Linux 或 macOS 下执行find ~/.m2/repository -name *.lastUpdated -exec rm -rf {} \;清理之后执行一次mvn clean package -U正常情况下就能重新拉取插件。如果清理后仍然 not found再考虑定点删除org/springframework/boot整个目录然后重新构建。这里也说说为什么我不推荐随便删整个.m2一方面下载量大另一方面如果公司内部有需要特定版本依赖的老项目本地仓库里保留的旧版本可能已经被私服清理了删了之后连私服也拉不回来问题就升级了。操作前如果有巡检脚本或构建记录可以先确认项目用到了哪些依赖版本避免误删后无法恢复。4.5 镜像、私服和代理的常见连锁反应这一个章节要单独拎出来讲因为“插件 not found”在设置了镜像或代理后会有完全不同的表现形态。如果你的 settings.xml 配置了阿里云仓库mirror idaliyunmaven/id mirrorOfcentral/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror正常情况下 Spring Boot 插件会被重定向到阿里云仓库而阿里云公共仓库的元数据是同步自 Maven Central 的所以插件能正常解析。但如果你用的是公司内部部署的 Nexus 仓库它的maven-metadata.xml可能只同步了 group 级别没同步 versions 级别或者仓库管理员开启了“按需从中央拉取”但中央仓库拉取超时也会造成 not found。遇到这种情况我的建议不是临时改镜像而是直接问仓库管理员要一份可用的pluginRepositories配置。通常私服管理员会给出类似pluginRepositories pluginRepository idcentral/id urlhttps://repo1.maven.org/maven2/url /pluginRepository /pluginRepositories这与依赖仓库是两个独立配置别偷懒只配一个。很多内网环境的坑都出在“依赖能拉插件拉不了”本质就是 pluginRepositories 缺失。代理场景更容易踩雷如果你的网络访问 Maven Central 需要走公司 HTTP 代理settings.xml 里要配置proxies proxy idinternal-proxy/id activetrue/active protocolhttp/protocol hostproxy.company.com/host port8080/port nonProxyHosts*.company.com|localhost/nonProxyHosts /proxy /proxies代理配置错误时表面症状是网络超时或者连接失败但 Maven 插件解析失败后打出的错误有时候也会收敛为not found形式容易误导排查方向。所以看到 not found 时先看完整堆栈和日志确认有没有更底层的原因而不是只盯着那两行红色文字。5. 实操心得我从多次排障里沉淀的几点体会5.1 保持 Maven 配置的最小化我见过大量团队把 settings.xml 搞得极其复杂mirror、profile、server、proxy、pluginRepositories 几十行配置单文件三五百行都是常事。一旦出问题排查成本极高。更稳妥的做法是一份精简的 settings.xml只保留必要镜像、私服凭证和本地仓库路径其余一律默认。不需要魔法配置的时候就让它干干净净的。Maven 的默认 Central 仓库本身就带完整的maven-metadata.xmlSpring Boot 插件官方一直在维护只要网络能访问几乎不会出现插件解析失败。很多 not found 问题的根源反而是自己加的“优化配置”破坏了默认行为。如果你不确定当前 settings.xml 有没有被团队模板污染可以直接临时换一个空配置mvn clean package -s /tmp/empty-settings.xml如果empty-settings.xml里只放空settings标签构建反而成功了那问题必然出在原 settings 的某个节点上对比两份配置逐项排查即可。5.2 优先让 IDEA 和命令行用同一版本 Maven如果把 Maven 换成一个测试版本、某个团队自定义发行版、或者 IDE 内置版本各种隐藏行为差异会浮现出来。最典型的例子是 Maven 3.8.1 和 3.9.x 对 HTTPS 仓库的默认处理方式有差异某些情况下 3.8.1 访问走 HTTP 的私服没问题3.9.x 却强制要求 HTTPS。插件 not found 在这种场景下会因为网络握手失败而触发。所以我的建议很直接锁定一个经过验证的版本比如 3.8.8 或 3.9.6团队统一。IDEA 的 Maven home path 和命令行mvn指向的安装目录保持一致settings.xml 都用用户目录下的默认文件不要在不同工具之间各配一套。毕竟排查问题已经够累了没必要让工具版本成为额外变量。5.3 慎用强制更新分清-U和-o的使用场景-U很香但不是一个无脑使用的参数。在某些网络环境不佳或私服负载高的场景下-U会触发大量的元数据刷新请求让整个构建变得缓慢甚至因为远程服务器限流而出现间歇性失败。我更推荐这样用首次构建失败且怀疑本地缓存有问题用mvn clean package -U。连续多次构建已经稳定不要每次加-U。完全离线或仅内网环境使用-o强制离线模式这样 Maven 能明确告诉你哪些依赖缺失而不是反复尝试从不可达的仓库获取。使用-o的另一个好处是如果离线模式下插件仍然 not found说明本地仓库根本没有插件文件问题点一目了然如果离线模式下能成功说明插件存在但在线模式下解析逻辑有问题比如镜像配置把请求导到了错误路径。这本身就是一种很好的排查分诊方法。5.4 用企业私服时插件同步策略务必提前确认企业私服是双刃剑。用好了团队构建稳定用不好就变成神秘的 not found 生产器。坦白说我用过的最大教训就是默认信任私服上的插件元数据同步功能直到某天插件版本升级才发现私服只缓存了依赖的 jar插件目录下的 metadata 一直没更新。提前确认几件事私服是否定期同步 Maven Central 的插件元数据不同仓库管理器配置不同。私服是否对所有 groupId 都开启代理还是只放行了特定的 jar 构件。私服管理员是否设置了仓库分组并确保pluginRepositories实际指向的是能够覆盖 Maven Central 内容的仓库组。像 Nexus 和 Artifactory 这类制品库默认代理仓库都能覆盖 Central但很多管理员为了节省磁盘空间会开启“只缓存被请求过的构件”策略。也就是第一次请求某个插件时才去 Central 同步一次如果同步恰好失败本地私服就会留下一个“空指针”缓存后续请求永远拿不到真实数据。遇到这种场景最好是让管理员手动清除一次该插件的缓存记录或强制触发远程同步。改项目配置解决不了私服缓存问题方向要选对。6. 实战记录一个老项目从报错到恢复的完整过程为了让你更直观地理解这些排查方法如何组合使用我拿一个真实场景复盘一遍。项目背景Spring Boot 2.7.18多模块 Maven 工程IDEA 2024.2Windows 11Maven 3.9.6使用公司私有 Nexus 仓库。某天拉取最新代码后执行mvn clean package报出Plugin org.springframework.boot:spring-boot-maven-plugin not found。我的排查顺序如下第一先在命令行执行mvn clean package -DskipTests -U结果依然报错。这说明不是 IDEA 配置孤立问题命令行同样受影响。第二执行mvn help:effective-settings查看实际生效配置发现 pluginRepositories 节点只有一个 central且 central 的地址被 mirror 重定向到了https://maven.aliyun.com/repository/public。第三打开浏览器访问阿里云的 metadata 路径发现插件版本存在且版本列表里包含 2.7.18。到了这一步可以基本排除“远程仓库根本没有该插件”的可能。第四检查本地仓库ls ~/.m2/repository/org/springframework/boot/spring-boot-maven-plugin/2.7.18/结果显示目录下只有一个_remote.repositories文件和两个.lastUpdated文件。问题基本定位本地仓库中的插件下载不完整Maven 认为这个插件已经尝试过下载不再发起新的网络请求。第五删除该插件目录rm -rf ~/.m2/repository/org/springframework/boot/spring-boot-maven-plugin/重新构建一切正常。从报错到解决整个过程不到十分钟。这个 case 里没有复杂的项目结构问题纯粹是 Maven 下载中断留下的脏数据。很多人在网上搜半天配置方案其实根源可能就是一次断网。这也解释了为什么我在前面一直强调看到 not found先检查本地仓库目录再检查远程仓库能不能访问最后才去动项目配置。顺序反了排查效率会大幅下降。7. 最后说一点自己长期使用 Maven 的体会做了这么多年项目从 Ant 换到 Maven 再接触 GradleMaven 给我的感觉仍然是“配置不复杂但对细节要求高”。Plugin not found这个报错是很多 Spring Boot 新手遇到的第一道坎也是很多老手偶尔还会翻车的暗礁。它本身并不难解决难的是你想不想快速想到可能的方向是否缺版本号、是否本地缓存脏了、是否 pluginRepositories 没配、是否 IDEA 与命令行配置不一致。我自己的习惯是每次新起一个 Spring Boot 项目第一步就把根 POM 的 parent 写明白第二步确认命令行mvn -v和 IDEA 的 Maven home 一致第三步清空一次.m2里的 Spring Boot 插件目录只用一次后面几乎不会再用。这三步做完基本可以把插件 not found 出现的概率降到极低。如果你此刻正被这个报错卡住不用焦虑按照我上面梳理的顺序一步步走大概率很快就能解决。最怕的就是网上随便抄一个配置改上越改越乱。Maven 这个工具的设计逻辑其实很干净它只会去找配置里明确告诉它的仓库然后按版本号拉取构件。你把这两件事核对清楚所谓奇怪的问题最后都会变得一目了然。
阅读完成 · 觉得有帮助？
