我今天以一种有趣的方式被烧伤了:

class MyClass extends FooClass {
    String a = null;

    public MyClass() {
        super();     // Superclass calls init();
    }

    @Override
    protected void init() {
        super.init();
        if (something)
            a = getStringYadaYada();
    }
}

看到错误了吗?结果是，在父类构造函数被调用之后才调用a = null初始化式。由于超类构造函数调用init()， a的初始化之后是a = null初始化。

我今天以一种有趣的方式被烧伤了:

class MyClass extends FooClass {
    String a = null;

    public MyClass() {
        super();     // Superclass calls init();
    }

    @Override
    protected void init() {
        super.init();
        if (something)
            a = getStringYadaYada();
    }
}

看到错误了吗?结果是，在父类构造函数被调用之后才调用a = null初始化式。由于超类构造函数调用init()， a的初始化之后是a = null初始化。

这两种方法都可以接受。注意，在后一种情况下，如果存在另一个构造函数，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.

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

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

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