为何Kotlin中的可选类型需显式初始化？

Great question! Let's break down why Kotlin forces you to explicitly initialize nullable var properties with null, while Swift lets you skip that step entirely.

First, let's recap the behavior you're seeing:

• In Kotlin, this throws a compile error:

  var myString: String? // Error: Property must be initialized or be abstract
  

• But adding = null fixes it immediately:

  var myString: String? = null
  

• Over in Swift, var myString: String? automatically defaults to nil without any extra code.

So why the difference? It all comes down to Kotlin's core design priorities:

1. Explicitness is king when it comes to null safety #

Kotlin was built from the ground up to eliminate the dreaded "NullPointerException" by making nullability explicit. Requiring you to write = null isn't just nitpicking—it's a way to ensure you're intentionally setting that property to null, not just letting it default there by accident.

Swift also has null safety, but it takes a more relaxed stance with implicit nil defaults. Kotlin's team chose to lean harder into explicitness here because it reduces the chance of bugs where you forget a property starts as null and try to use it later without checking.

2. Consistency across all property types #

In Kotlin, every property needs a clear initial value before it's used—no exceptions. For non-nullable vars, you can't leave them uninitialized:

var myNonNullString: String // Error: Property must be initialized or be abstract

For immutable val properties, you also have to initialize them explicitly (either at declaration or in a constructor). If Kotlin let nullable vars skip initialization and default to null, it would break this consistent rule. The team decided keeping the language's behavior predictable was more important than saving a few keystrokes.

3. Avoiding confusion with late-initialized properties #

Kotlin has the lateinit modifier for properties you plan to initialize later (before using them):

lateinit var myLateString: String

If nullable vars could be left uninitialized, it would create ambiguity: did you forget to set a value (like with lateinit), or did you actually want it to be null? Explicitly writing = null removes that confusion—anyone reading your code knows exactly what you intended.

4. Enforcing a clear initialization flow #

Kotlin enforces that all properties are fully initialized before an object is created (unless they're abstract or marked lateinit). If you leave a nullable var uninitialized, the compiler can't tell if you meant to set it later or just wanted it to be null. By requiring = null, you're spelling out your intent for both the compiler and other developers.

At the end of the day, it's a trade-off between conciseness and safety. Kotlin prioritizes making null-related behavior obvious to prevent bugs, even if it means typing a little extra code.

内容的提问来源于stack exchange，提问作者Andy