使用依赖注入或延迟初始化总是更可取的，已经在其他回答中详细解释过了。

当你不想或不能使用这些模式时，对于基元数据类型，有三个令人信服的原因，我可以想到为什么最好在构造函数之外初始化类属性:

避免重复=如果你有多个构造函数，或者当你需要添加更多构造函数时，你将不必在所有构造函数体中重复初始化; 改进的可读性=你可以很容易地从类外部判断哪些变量需要初始化; 减少代码行数=在声明时每执行一次初始化，构造函数中就会减少一行。

第二个例子是惰性初始化。第一个是更简单的初始化，它们本质上是一样的。

这两种方法都可以接受。注意，在后一种情况下，如果存在另一个构造函数，b=new b()可能无法初始化。将构造函数外部的初始化器代码看作一个公共构造函数，代码将被执行。

There is one more subtle reason to initialize outside the constructor that no one has mentioned before (very specific I must say). If you are using UML tools to generate class diagrams from the code (reverse engineering), most of the tools I believe will note the initialization of Example 1 and will transfer it to a diagram (if you prefer it to show the initial values, like I do). They will not take these initial values from Example 2. Again, this is a very specific reason - if you are working with UML tools, but once I learned that, I am trying to take all my default values outside of constructor unless, as was mentioned before, there is an issue of possible exception throwing or complicated logic.

另一种选择是使用依赖注入。

class A{
   B b;

   A(B b) {
      this.b = b;
   }
}

This removes the responsibility of creating the B object from the constructor of A. This will make your code more testable and easier to maintain in the long run. The idea is to reduce the coupling between the two classes A and B. A benefit that this gives you is that you can now pass any object that extends B (or implements B if it is an interface) to A's constructor and it will work. One disadvantage is that you give up encapsulation of the B object, so it is exposed to the caller of the A constructor. You'll have to consider if the benefits are worth this trade-off, but in many cases they are.

其实很不一样:

声明发生在构建之前。因此，如果在两个位置都初始化了变量(本例中为b)，构造函数的初始化将取代在类级别所做的初始化。

所以在类级别声明变量，在构造函数中初始化它们。