成员变量由JVM在类加载准备阶段赋予安全默认值以兜底，局部变量必须显式赋值因编译器可精确追踪其读写路径；二者设计差异源于编译期可验证性与运行期不确定性的权衡。
Java 中成员变量能隐式初始化，而局部变量必须显式赋值，核心不在“能不能”，而在“该不该由谁来负责”——这是编译期可验证性与运行期不确定性共同决定的设计取舍。
成员变量有默认值，是因为编译器管不了赋值顺序
成员变量属于对象状态，它的读写时机由运行时方法调用决定。比如一个 name 字段，可能在构造方法里赋值，也可能在某个 setter 里赋值，还可能在 getter 调用之后才第一次赋值。javac 编译时根本无法静态分析出“哪一行先读、哪一行后写”。放任未初始化的内存被读取，可能暴露栈/堆中残留的敏感数据（如前一个用户的 token、密码片段）。所以 JVM 在类加载的准备阶段就统一赋予安全默认值：数值型为 0，布尔型为 false，引用类型为 null。这不是纵容疏忽，而是兜底保障。
局部变量必须显式赋值，是因为编译器完全看得见读写路径
局部变量作用域窄、生命周期短，只存在于某个方法或代码块内。它的声明、赋值、读取都在同一个编译单元里，顺序是线性的、确定的。javac 可以精确追踪每个变量是否在首次读取前已被赋值。一旦发现 读取前无赋值，就直接报错，不给运行时留隐患。这种强制不是限制，而是提醒：你本意可能是忘了写，而不是真想用 0 或 null。
默认值 ≠ 合理值，业务逻辑才是关键
- 成员变量默认为 0 或 null，技术上安全，但业务上往往不合理。比如用户年龄默认 0、订单金额默认 0.0，可能绕过校验逻辑，导致“空购物车也能结账”这类隐蔽 bug。
- 局部变量若也允许默认值，开发者更容易忽略初始化，尤其在分支多、嵌套深的代码中。一个没走完的 if 分支，可能让变量始终未赋值，却因默认值“侥幸通过编译”，最终输出错误结果。
底层机制差异强化了这一设计
成员变量随对象分配在堆上，由 JVM 统一管理生命周期；局部变量存在栈帧的局部变量表中，复用频繁、空间紧凑。显式赋值要求，配合栈帧结构，让 JVM 更容易做逃逸分析和内存优化。而成员变量的默认初始化，是类加载机制的一部分，天然适合在准备阶段批量完成。
