打开 3liantieerji 后台管理后端项目跑mvn package控制台直接红屏[ERROR] Failed to resolve dependencies for project ...: Could not find artifact com.hbisdt:flowable-engine-common:jar:6.7.2 in ... systemPath .../lib/flowable-engine-common-6.7.2.jar does not exist两个 jar 都走 system scope指向项目内lib/目录。我ls lib/里面只有一个 README.mdjar 文件压根不在。编译和打包全卡在这里。system scope 的 jar 为什么丢了先看 README 写了什么。里面说得很直白lib 里放的是修改过源码的 flowable 工作流定制包主要兼容金仓和达梦数据库。但 jar 本身没进 git——大概率是.gitignore里把lib/*.jar排掉了或者有人图省事只提交了 README 当占位。我顺手对比了同仓库下的 sj-server 项目。sj-server 是精简版没有工作流模块pom 里根本不需要 flowable 和 liquibase所以它编译没问题。这解释了为什么只有全功能后台会挂。关键判断这两个 jar 不是 Maven Central 能直接拉下来的标准版本是内部改过源码的定制包。就算网络通、Maven 镜像配好了systemPath指向本地目录Maven 不会帮你下载。定制 jar 从哪来跨项目找备份恢复路径其实只有一条找到同一套定制包的备份。我在全流程项目另一个更大的工程的lib/目录下搜了一下两个 jar 都在flowable-engine-common-6.7.2.jarliquibase-core-4.5.0.jar校验方式不复杂对比两边的 README.md 文案一致jar 大小相同确认是同一套定制版本。直接cp到 3liantieerji 的lib/目录下重新mvn package依赖解析这层过了。第二层编译错误DTO 类缺失依赖通了之后编译还是红。这次报错在SysDictManagerServiceImpl.java[ERROR] .../SysDictManagerServiceImpl.java:[xx,x] cannot find symbol: variable DictManageImportDTO location: package com.hbisdt.dqbasic.kernel.business.basic.dict.pojo.responseDictManageImportDTO这个类在com.hbisdt.dqbasic.kernel.business.basic.dict.pojo.response包下但当前项目里找不到。排查方向这个类来自哪个依赖 jar大概率是dqbasic-kernel相关的内部包需要确认版本是否匹配同文件里是否还有其他引用了同一个包下但本地不存在的类截断处线索指向同文件里 Di…推测还有同类缺失检查mvn dependency:tree看这个内部依赖到底有没有被正确引入这一步还没走完但定位思路清晰system scope 的依赖问题解决了接下来是普通 compile scope 下内部包版本不对齐的问题。可带走的三条排查路径碰到systemPath下 jar 缺失别急着去 Maven 中央仓库找。按这个顺序走先看 lib 目录和 README——确认文件是缺失还是根本没提交README 通常会说明 jar 的来源和定制点找同仓库/同团队其他项目的备份——定制包往往在多个项目间共享find / -name flowable-engine-common-6.7.2.jar或直接在同事机器上拉一份用mvn dependency:tree区分 system scope 和普通依赖——system scope 的 jar 不会因为-U强制更新而自动下载必须本地文件存在最后一条教训写进项目 README 或 CI 配置里system scope 依赖必须在构建前做文件存在性检查[ -f lib/xxx.jar ] || exit 1否则每次新人 clone 完就红屏排查成本全花在找 jar 上了。做自动化这几年最耗时间的从来不是写代码是摸清每个平台的脾气。这篇里提到的坑都是真金白银踩出来的。如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作——可以在评论区说说你的场景我看看能不能自动化掉。