Quarkus/Arc 这么简洁又高效的编译时依赖注入怎么做到的？

[FallMonkey]

最近在调研新的 Java 框架，发现 Quarkus 这个好东西，自己起了个项目，然后看了看相关文章，发现在依赖注入这边使用的 Arc 框架，怎么说呢，简直 too good to be true - https://quarkus.io/guides/cdi-reference

语法上几乎是现有依赖注入框架里最简洁那一档的（ Guice, Dagger2, SpringDI, H2K ，etc)，几种主流的注入方式也都支持，而且并不会有其他编译时依赖注入框架需要你把所有依赖都写一遍的问题。性能分析(jar 包大小，运行时内存占用，依赖加载速度）这边简直都让我怀疑自己这么多年关于运行时依赖注入的信条是否单纯是自己技术太差导致的。

如果说这个编译时依赖注入的框架，牺牲一点点生成的包的大小（可能这个一点点其实在有些项目就不能忍？），换来性能更强，语法更简洁，代码 bug 更少。那么为什么我们还要用任何运行时的依赖注入？

还是我对依赖注入框架本身导致的 overhead 有误解？

[warcraft1236]

不懂，只是觉得跟 Spring 比的优势并不是很明显

[knives]

之前没关注，从文档来说看上去挺不错的。貌似和 HK2 一样都需要预先生成索引？不过功能倒是比 HK2 强大太多。

[FallMonkey]

@knives 对的，而且语法居然和那些运行时注入的框架一样简单。。。Dagger2 这种虽然也是编译注入，但是要干的额外工作还不少。

[cheng6563]

Spring 慢就慢在要扫包，而且一些依赖还要再扫包。这原因也是 jar 包的结构造成的。

[mind3x]

也没有什么特别复杂的，把运行时扫描 annotation 构建依赖图的工作移到编译预处理阶段了。

以前对长期运行的服务来说，DI 再慢也不是多大个事，毕竟主要只影响启动时间。随着容器化特别是 AWS Lambda 的出现，小服务 /快速 /按需启动变成重要特性，特别是 GraalVM 使得 Java 服务也可以静态编译，以往臃肿的运行时扫描注入就不合时宜了。

现在 Spring 也在跟上。

[FallMonkey]

@mind3x 但是主流了好多年的运行时注入的好处呢，打包出来的 jar 比较小？

[wolfie]

@FallMonkey #6
运行时更灵活？根据 apollo 、nacos 这种配置中心，运行时动态创建 bean ，动态的指定 bean 。

[FallMonkey]

@wolfie 这个的确到点子上了，如果编译时怎么也做不到这一点。还是 v2 能人多。