It is more intuitive and simple to write the configuration in the code (some configurations have been done by spring boot itself), using chain programming. . .
Using maven dependencies is more refreshing.
But I think there are more pitfalls

Because there are many configurations in spring that will not be changed once the configuration is completed, and there is no need to change, such as the dependencies of most beans. It makes no sense to put all these configurations that will not change in xml. It will only make the configuration larger and larger. Spring 3.x was criticized for having too many configurations, and it has become configuration-based programming, which puts the cart before the horse. , so it is actually better to put these nearly static configurations in the code.
XML is more convenient to modify, and it can take effect without compilation, so it is better to put those configurations that need to be changed according to the environment and business in XML.
Spring Boot absorbs the convention-based configuration of Rails, which reduces the configuration a lot. However, if you are not familiar with how its underlying configuration is configured, you may encounter many problems.

I feel a little speechless about this too.
If you must explain, the Java configuration before the Spring era was imperative (written down all the way, depending on the execution order), which was changed to XML declarative. In the Spring Boot era, declarative Java configuration was implemented again (scattered in multiple annotated methods, does not depend on execution order).
In addition, many configurations can be overridden with application.properties. This should have been done a long time ago!

spring的发展，采用了约定优于配置的原则。
1.xml中维护bean之间的依赖关系，随着业务逻辑的增长变得臃肿。
2.在.java中的配置效率是没有xml效率高的。