问题1.关于maven的依赖传递问题，为什么有时候你子项目的依赖可以传递过来，而有时候却没有？

这个问题，一般来说很少有人会注意到，就算用了那么多年的maven，不实际的踩个坑，也肯定不会发现，好巧不巧的，我就踩进了这个坑，
下面来描述下：
我在重构项目的过程中，发现有些项目中的依赖引入很混乱，导致很多都存在依赖冲突问题，对于这样的项目，我是看不下去的，那么咋办呢，当然是改咯；
也简单，首先就是将所有的jar版本都交给父项目管理，当我改造完的时候，突然发现，有些项目报错了，很多原来可以用引用到的jar，都找不到了，刷新依赖也没有，但是根据maven依赖的传递规则，这些都已经在其他的jar中引入，为什么我这边没有依赖进来呢，而且我也并没有删除jar，只是交给父pom管理了而已；

情况就是这么个情况，遇到问题那当然要思考了，究竟是为什么呢，尝试着还原以下看看，然后刷新依赖，jar又回来；
那么问题就找到了，肯定是父子项目管理jar包的方式导致依赖没有传递的；原来是直接在子项目中申明的jar依赖，现在我将这个jar交给了父pom去管理，这个时候jar包就不见了，由此可见，是这种方式导致；思考题：是不是只要将jar交给父pom去管理就会出现这种情况呢？那么能不能交给父pom管理，同时依赖也允许传递呢？

问题2:为什么不要在get，set方法中加入一些业务逻辑进去，会有什么问题吗？

这个问题基本上的coder应该都知道，尽量不要在实体的get，set方法中加入一些业务逻辑，或者说做一些其他操作，但是为什么不要这样做呢？这样做会有什么后果呢？我相信一大半的人肯定能说出一些东西来，但是肯定不会有实质性的东西；
接下去，我来说说我踩到的坑；也是在重构过程中，我发现公司的返回体很乱，导致前端接收值判断的时候，需要有好多种逻辑，判断好多个字段，有很多的额外兼容操作；本着想要省代码，省逻辑，最简化，统一的原则，我就想把这些全部统一，但是因为前端app有版本的概念，很可能后端，一调整，会导致整个app都报错，这就得不偿失了，那么只能通过加字段的形式去解决这个问题，然后新版本统一用一个字段，同时不影响老版本的使用；

说干就干，加了几个字段，同时在get，set中对这些新字段进行赋值和取值，刚开始觉得没什么大碍，但是后来同事在调试过程中，发现旧的一些接口返回的内容，在新的这边没有获取到，（说明：旧接口用的还是老得返回体），这个时候我就相当疑惑了，这是为什么呢，明明实体都有相同的字段，然后虽然返回体是其子类，但是java有上行转换啊，自己会转过去呀，但是实际结果是没有，然后查资料，发现spring，feign的实体转换，是通过get，set去转换的，所以我猜可能是因为这个问题，后来我就将get，set方法变得纯粹，去除那些赋值操作，然后试一把，发现没问题了；所以问题就出来了；

总结到这里差不多了，要去改bug了😂😂。。。。。。。