关于Spring文档，有两件事似乎相互矛盾。我知道我可能在考虑这个问题，但是我想看看其他人对此有何评论：
约定的存在是否表示Spring有一种处理方法？
Spring在说有约定的情况下又怎能不自以为是？
就像我说的那样，我可能在考虑这个问题...
答案 0 :(得分：1)
我认为你把这两个句子混在一起了。
它并不能说明Spring约定没有被接受。
惯例总是固执己见。
第一点是：
适应不同的观点。 Spring拥有灵活性，是 没有对应该如何做的看法。它支持广泛 各种角度的应用需求。
第二个是：
它基于Spring框架，更倾向于约定俗成 配置，旨在使您尽快启动并运行 可能。
事实上，Spring尊重了这两点，但是它们并没有应用于同一级别。
第一点涉及Spring作为设计应用程序的选项提供的灵活性。
第二点是Spring提供的减少配置模板代码的约定，优于配置方式。无论您要使用什么选项，这都是正确的。
以下是一些带有示例的细节：
第一点意味着Spring提供了多种方法来做某事。它不会强迫您使用特定的方法来实现您的目标。
我会给你一些例子来说明这一点。
例如，假设您要执行一些持久性操作。 Spring提供了支持以多种方式实现它的方法：JDBC，JPA，NoSQL ...
而且，当您进一步深入研究时，对于较低级别的事物也是如此。
作为数据持久性帮助者，Spring提供了很多东西：JdbcTemplate，CrudRepository，JpaRepository and，因此......
另一个示例：执行依赖项注入时，没有一种唯一的方法：可以使用setter，field，构造函数甚至工厂方法注入。
这种事情就是 Spring的灵活性。
关于第二点：关于配置的约定是Spring的非常基本的内容。
它依赖于以下事实：当您要使用Spring提供的任何特定组件，功能时，默认情况下将使用通用的默认配置对其进行设置，这也是大多数用户所需的通用方式。
例如，bean比原型更常见于单例。因此，Spring默认情况下为bean配置原型作用域。其他示例：明确命名每个bean都是地狱。因此，Spring使用简单类名的驼峰式大小写来定义bean名称。
最后一个例子表明两点并不矛盾：您有多种方法来指定bean的依赖项注入。
如果您使用参数定义构造函数，则会自动应用注入选项（ flexibility ）（基于配置的约定）。您不需要指定@Autowired，因为Spring使它成为惯例。
您在Spring和Spring Boot中有数百个类似的示例，这些示例将进一步促进约定俗成的配置方式。
答案 1 :(得分：1)
约定的存在是否表示Spring有一种处理方法？
“一种开箱即用的方式，旨在使入门变得容易”。
Spring在说有约定的情况下又怎能不自以为是？
公约：一种通常用于完成工作的方式，尤其是在特定区域或活动中
Spring当然具有约定（#2），但会努力提供一切机会提供替代解决方案（#1）来替换默认约定。
如果我要一起重写冗长的#1和#2：
Spring怀着对常规默认值的看法的灵活性，这对于大多数工程师来说应该可以简化实施（即“常规配置”）。但是，如果您选择覆盖常规默认值，Spring对于最终应如何实现事情没有意见。