业务场景：当前我们项目引入了公司自研的一些公共框架组件，比如SSO单点登录jar包，文件上传服务jar包等公共组件，开发新功能，本地验证好之后，部署流水线，报出一些jar包版本的整改漏洞问题，无法跑通流水线

• 通过流水线平台显示有漏洞的依赖包，逐一排查，这里存在有两种包类型，一种就是我们自己项目直接依赖的包版本问题，这些占少部分，直接修改pom文件的依赖版本号，根据内部平台查询该依赖包有哪些其他可行的版本号兼容的，就直接修改即可
• 主要问题还是在于，我们引入了多个公司自研的框架jar包，而这些jar包又引入了一些相关的jar包，这些包的版本存在漏洞问题，需要去升级这些包的依赖版本，那推动这些自研包团队去修改升级包，我们再去直接修改这个自研包版本，效果不好，他们团队需要花时间修复代码，那最后我们就利用 dependencyManagement 锁定依赖库的版本号

<!-- 漏洞修复-->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.common.log</groupId>
                <artifactId>log-class</artifactId>
                <version>1.2.12</version>
            </dependency>
        <dependencies>
    </dependencyManagement>

因为那些是间接依赖的包，我们无法直接像我们直接依赖的包 ，能直接去修改版本号，所以需要通过这个dependencyManagement 依赖管理标签去强制锁定，我们这个module模块中代码引用到的这些api接口功能时，才会去强制锁定使用这个指定的版本，而不会再去用引入框架jar包内的间接引用的版本了，可以说这也是一个 最短路径依赖原则，因为业务代码就是在该module工程下的，再加上是在这个模块的pom文件下定义的这个依赖管理指定版本号

直接依赖包的标签路径是：外层没有dependencyManagement  

 <dependencies>
        <dependency>
            <groupId>com.xx</groupId>
            <artifactId>xx</artifactId>
            <version>3.15.0</version>
        </dependency>

 </dependencies>

 这里还有遇到一个问题，就是jar包版本升级之后，会导致以前写的一些代码会报错，这里主要原因还是因为高版本的jar包，针对某些api接口方法的形参做了一些调整，增加了一些固定的形参属性，需要传递参数，这里只能是手动去改写代码，兼容高版本，甚至可能有些导入导出的接口功能，跨版本过大，导致旧api接口都发生大改动，比如接口包名，类名，接口名，路径等等