记录一个因为Dubbo调用和Spring注入不规范导致的注入问题

前言

已经在新的公司待了大半年了，在这大半年里面使用的技术就是Spring全家桶以及阿里家的一些框架，由于之前写代码有些放飞自我，导致一些隐藏的问题在现在慢慢的暴露出来了，最近就发现了一个依赖注入的问题

问题来源

因为公司项目有多个模块，有些web端使用的方法在移动端也需要使用，于是就使用了Dubbo来调用，减少重复工作。但是在最近启动项目的时候就经常报错

一看错误首先想到是不是有一个接口被实现了多次，于是全局搜索一下

发现问题

发现并没有重复实现的问题，于是工作两年半的我一时有点懵逼，怀疑是不是idea的缓存导致了什么问题，因为不是一次遇到过因为idea的缓存导致的莫名问题，清除工作区缓存，重启idea，启动项目，发现报错依旧。。。

理一下思路，报的错是因为，在引用Bean时，发现了两个相同的Bean，但是实际只有一个实现类实现了这个接口，那么就有可能是在注入的时候被注入了多次导致的，于是查看了一下注入Bean时的操作，于是发现了一个大问题。。。。

在同一个模块下面出现了两种注入方式，因为程序的原始版本中已经大量使用的注入方式就是使用Lombok的@RequiredArgsConstructor来生成构造方法进行注入的，所以后面我们在写代码注入的时候，就大量使用了构造方法注入，这种方式也是Spring官方目前最推荐使用的注入方式，但是在其他模块使用的时候，就使用的@DubboReference来进行服务调用，导致在当前服务进行注入的时候找到了多个相同的实现方法

解决问题

找到问题后就要开始解决了，将所有和Service同一个模块下面的代码改为使用构造方法注入，远程调用的模块使用@DubboReference来调用，编译，启动

解决问题！

其实在报错的时候Spring就为我们提供了解决办法，使用@Primary来强制标记使用的实现类，这样的不话不管出现多少了实现类，最后都会只使用被标记的那个类，这种算是特殊情况下万不得已才使用的方式，一般在日常的中只要代码结构合理基本(当然每个项目不同，也不能说完全遇不到)都不会出现多个实现类的这种问题

小结

其实这个问题并不是什么大问题，主要是在日常写代码的时候没有经过脑子，太过于放飞自我了，以后在工作中还是得要细心，不然白白浪费时间

补充

最开始也是有点一筹莫展，因为压根就没有想到问题的根本原因这么简单，突然在github上也遇到一个兄弟遇到了相同的问题，受到启发，于是回去检查注入方式

参考

1.dubbo2.7.13升级到3.0.11版本 兼容性问题启动报错 Dubbo2.7.13 Upgrade to version 3.0.11 Compatibility Problem Start Exception