目录■前言■吐槽■暂时解决策■对应的java代码■风险隐患一按类型注入Autowired会直接启动失败隐患二按名称注入Resource(name user)会取错对象隐患三MyBatis 层面的别名冲突依然存在■前言基盘代码貌似有问题呀。。。。(工程里面 和 服务器使用的jar里面有不同包同名的类即SpringBean同名。。。)Project AAA中有aaa.bbb.ccc.mapper.TTBeanProject AAA中使用AAA-bb.jarAAA-bb.jar中有aaa.bbb.ccc.mapper.gen.TTBeanTTBean重复了。。。。把这个基盘代码Bean重复的问题提了出去那边的开发说什么使用 MyBatis的FQDN可以解决。可是查了一下MyBatis的FQDN解决不了Spring的同名Bean冲突问题。■吐槽不用Maven管理第三方jar。。。是Resin的Accel PlateForm Library 其中一个AAA-bb.jar还是后期修改的。完全TMD不整合。。。。■暂时解决策Resin的JVM启动参数中添加下面内容spring.main.allow-bean-definition-overridingtrue-Dspring.main.allow-bean-definition-overridingtrue明天去试试。暂时先让服务启动起来。。。■对应的java代码public static void main(String[] args) { SpringApplication app new SpringApplication(MyApplication.class); app.setAllowBeanDefinitionOverriding(true); app.run(args); }■风险隐患一按类型注入Autowired会直接启动失败如果你的某个 Service 需要注入 com.a.User但容器里最终保留的是 com.b.User因为后者包扫描顺序靠后。此时 Spring 会提示NoSuchBeanDefinitionException: No qualifying bean of type com.a.User available因为 com.a.User 已经被覆盖并移除了启动虽然过了但运行到注入这个 Bean 的地方就会报错。隐患二按名称注入Resource(name user)会取错对象即使注入成功你拿到手的很可能是 com.b.User 的实例但你的业务逻辑是按 com.a.User 来写的。数据类型可能不同调用方法时极大概率会抛出 ClassCastException 或 NullPointerException这种运行时的诡异错误比启动报错更难排查。隐患三MyBatis 层面的别名冲突依然存在请再次注意这个 JVM 参数只管 Spring 容器完全不管 MyBatis 的 typeAliasesPackage 扫描如果 XML 里你没有写 FQDN全限定名MyBatis 注册别名时依然会因为两个 User 同名而抛出 TypeException。既然你之前说“按照方案一配置了”在 XML 中用了 FQDN这个风险才被排除。