不能给依赖jar“打补丁”，因maven无官方patch插件，不支持构建时修改第三方jar源码；jar含编译后class，无法反编译修改再打包，强行操作会导致签名失效、校验失败、类加载冲突，且不可复现、不可审计、ci无法验证。
不能用“patch 插件”自动修复旧版本依赖的源码漏洞——Maven 本身没有官方 patch 插件，也不支持在构建阶段修改第三方依赖的源码。所谓“打补丁”，实际是针对你自己项目中的源码应用 .patch 文件，而非篡改已发布的 jar 包内容。
为什么不能给依赖 jar “打补丁”
第三方依赖（如 jackson-databind、commons-beanutils）是以编译后的 class 形式打包进 jar 的，其源码不参与你的构建过程。Maven 构建时只读取这些 jar 的字节码，无法反编译、修改、再打包。试图用 patch 命令去“修复” jar 内部文件，既不可靠，也违背依赖管理原则。
- 补丁工具（如 maven-patch-plugin）只作用于
src/main/java下的源文件，对~/.m2/repository/中的 jar 完全无效 - 即使强行解压 jar、打补丁、重打包，也会导致签名失效、校验失败、类加载冲突等严重问题
- 该做法不可复现、不可审计、无法通过 CI 流水线验证，生产环境严禁使用
正确修复依赖源码级漏洞的路径
发现 CVE 报告（如 CVE-2022-42003）指向某个依赖版本，应走标准升级或覆盖流程：
- 优先升级到官方修复版：查 mvnrepository.com 或厂商公告，确认哪个版本已修复该漏洞，然后在 pom.xml 中显式声明新版本
- 用 dependencyManagement 统一管控（尤其多模块项目）：在父 POM 中锁定安全版本，确保所有子模块继承一致版本
-
排除带毒传递依赖：若漏洞来自间接依赖，用
<exclusions></exclusions>移除它，再单独引入修复后版本 -
临时绕过（仅限紧急场景）：用
-Xbootclasspath/p:或自定义类加载器加载补丁 class，但需严格隔离、充分测试，且不是 Maven 构建行为
如果你真有源码级定制需求
仅适用于你自己维护并发布的内部依赖（如 company-utils），且你拥有其完整源码：
- 将该依赖项目克隆到本地，基于对应 tag 拉分支，应用社区 PR 补丁（git apply xxx.patch）
- 本地编译安装：
mvn clean install -Dmaven.test.skip=true - 在业务项目中引用该 snapshot 版本，并配合
<dependencymanagement></dependencymanagement>锁定 - 后续仍需推动该补丁合入上游，发布正式版，避免长期 fork 维护
真正安全、可持续的做法，永远是升级到已修复版本，而不是在构建里“偷偷打补丁”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
