maven依赖碎碎念：实际公司里的一些做法或坑
在一些小点的公司，或者是没那么复杂的项目里头，要么没有公司的maven私仓，要么即使有，整体的maven管理也会简单一些的。比如：
下面是典型的微服务/springboot的项目结构：a或b是parent project，其下有一些子模块继承parent，父模块也通过 引入各个子模块，子模块之间可以有依赖，如common都被各个子模块依赖，其他子模块之间也可以存在依赖
a-project common a1 a2 a3 b-project common b1 b2 b3一般在这种小公司里，两个project，a和b毫无关系，不产生依赖。
以a为例，在a里头，同一个project里头的互相依赖都是不需要mvn install就可以及时得到更新反馈的：比如说a1依赖common，在common里添加一个新方法，在a1里立即就能用，并不需要common子模块先install，这应该是IDE带来的好处，允许自己local maven 仓库 “没货”
project外的依赖就得自己local maven仓库 “有货” 了，要么就通过下载，要么就得本地执行mvn install到本地仓库里。
比如此时公司有个 company-common 是公司级别的公共依赖，a-project 和 b-project 都引用。若 company-common 有变动，要么：
- 下载 company-common 自己切换到合适的分支，然后
mvn install，让本地仓库 “有货” - 要么别人已经推送到公司私仓了，从私仓下载 （如果不是用SNAPSHOT版本的话需要修改 a 或 b 里头依赖的 company-common 的版本
为什么这里头第1种方法这么坑
有时候依赖关系比较复杂，在a编译报错的时候，你不一定能想到是 company-common 这个依赖需要更新，比如编译a的过程发现com.foo.bar.common.test.Foo这个类缺少，可能依赖关系不复杂的时候可以从common的包名联想到 company-common 这个依赖，一旦没这些经验，靠着包名你怎么知道这个类是在哪个jar包里呢？况且知道哪个jar（GAV）的时候害得去反推是直接还是间接引入。
你可能根深蒂固：凭什么需要我下载当前项目外的依赖到本地进行install，这一般人都只会想到我从公司私仓下载肯定会有，如果没有那就是有人没上传上去。
为什么有时候依赖关系会这么庞大和复杂呢？
a 项目里本身就有很多子模块，每个子模块之间可能存在依赖，子模块再去意外外部的依赖，另外被依赖的外部的也不一定是一个整体，比如 company-common 里头也可以有很多模块，不一定就整个被依赖。我们这里也只是举例了一个 company-common，如果更多类似 company-common 的时候呢？
依赖深度也可能非常深，可能 company-common 并不是在第一层，可能是间接甚至隔了好几层才被引入。
实际项目因为历史原因可能累积的屎山代码导致依赖关系_真的很复杂！！！_
附
maven里的SNAPSHOT和RELEASE版本，在实际中用的多吗？
大公司用得不多，SNAPSHOT 好处当然是当被依赖的jar可以随时改，依赖这个jar的项目不需要改依赖的版本号。大公司里一般都是固定的版本号，比如 X.Y.Z 或者 v1.17.9 之类的，或者是编译后会带个时间戳，比如 v1.17.9-20260101154134666 之类的。引用者可以写死引用的版本，比如<version>v1.17.9-20260101154134666</version>或者使用版本区间的写法如<version>[1.0.0,19.0.0]</version>
暂时写到这，后续有补充再说
