1、Quarkus是很好，但是 Spring Native 出现时，人们空i不愿意学习完整的其他堆栈。
GraalVM的一个人昨天在一次会议上： Spring Native 甚至会包含在下一个主要的 Spring Boot 版本中，该版本将在2022年秋季发布。
2、基本上是说迁移到 Quarkus 可能带来的好处并没有超过负面影响。
关于 Quarkus 的一些好处：
- 学习曲线，这比人们预期的要小得多，我一起工作的一些 Spring 开发人员在一天左右的时间里感觉 Quarkus 比 Spring 更容易，但我的经验是这取决于项目。
- 速度，Quarkus 只是更快（至少根据我参与的测试）并且在相同数量的资源上执行更多的工作，再次根据我参与的测试，应该提到的是，这是没有移动的为本地人。
- 开发者速度，我知道这听起来像个蹩脚的东西，但开发者快乐的想法实际上似乎奏效了，我和我认识的使用 Quarkus 的人似乎更喜欢它，并不是说我不喜欢 Spring Boot，当您考虑了一些框架，甚至 Spring Boot 也很高兴使用 :)
3、Quarkus存在不重视kotlin的问题，例如实时重新加载不起作用。
另一种情况下，属性的构造函数注入会不起作用，因此字段在运行时为空，尽管没有被标记为可空。
我经历过许多类似这样的奇怪错误，但随着时间的推移，它变得更好了，我绝对更喜欢 Quarkus 而不是 Spring Boot。
很遗憾，kotlin 似乎是二等公民
4、两者基准测试在性能上有巨大的差异，但无法确定其原因......。
主要原因是Quarkus在构建时做了传统Java在运行时做的事情。这包括。
- Classpath扫描
- 配置解析
- 初始化组件
Quarkus应用程序只包含运行时需要的类。这种预处理导致了更少的内存使用和更快的启动时间。然而，就像任何事情一样，也有取舍的问题。其中之一是，如果你是一个reflection发射的重度用户，Quarkus对你来说并不是很好。
完整的解释在这里：https://quarkus.io/container-first/
5、我去年一直在使用quarkus，它的文档似乎很缺乏，功能似乎也有点不足，它只是没有给人带来很多信心。也许对于一个简单的微服务来说，从Rdbms中暴露出粗糙的操作，quarkus是伟大的，但对于更复杂的应用程序来说，它似乎有点业余了。
6、如果我们处在一个新的环境中，只选择Quarkus和Spring，我毫不怀疑Quarkus将胜出。我以前用过它，在功能和性能方面都给我留下了深刻的印象。我也没有遇到任何可靠性问题或其他人报告的重大错误。
问题是，在已经有一个巨大的事实标准（Spring）的世界里，它是一个小众产品，而作为这样一个标准，它有一系列巨大的优势。文档、例子、开发人员的熟悉程度、库的生态系统等等都是Spring的巨大优势--而Quarkus则不然。我有时不得不深入到源代码中去寻找Quarkus问题的答案，仅仅是因为没有文档。
我并不反对使用新的框架--远非如此，我总是很好奇，愿意尝试新东西。但在生产/商业环境中，技术上的优势并没有超过整体上的劣势，IMHO。当然，可以说这是不公平的，因为Spring取得今天的成就要比它长一个数量级，但这就是现实。
7、Quarkus离 "生产就绪 "还很远......一些基本的功能，如数据库连接池仍然是错误的（在简单的数据库重启后，连接池一直是死的）......也许明年吧
8、Quarkus不仅仅是在生产中已经使用，而是在一些相当关键的系统中已经使用。例如，https://github.com/keycloak/keycloak。
虽然我毫不怀疑存在错误，但对我来说，它似乎可以用于生产。我们刚刚开始一项新的服务，在评估了一堆选项（Dropwizard、Boot、Micronaut等等）之后，选择了Quarkus作为基础。
DX是伟大的，相对于Spring这样的基于运行时/反射的DI框架，我们真的很欣赏它没有疯狂的、抽象的、复杂的堆栈跟踪，以及在编译时而不是运行时捕获问题。它是 "云原生 "的这一事实使得部署到现代可扩展架构的工作更加简单，而为Lambda部署建立原生镜像的能力也是一个额外的好处（尽管在我们的决定中并没有起到重要作用）。
无可否认，我们刚刚开始使用，还有很多东西需要学习，但到目前为止还没有抱怨。时间会证明一切。