java局部变量必须显式初始化，因其栈帧复用内存不自动清零，残留数据导致未定义行为；编译器通过确定性赋值分析强制所有执行路径覆盖初始化，确保安全与确定性。
Java 局部变量在未显式初始化前禁止使用，不是编译器“较真”，而是语言设计上对确定性与安全性的硬性保障——它不让你碰一个可能存着随机内存垃圾的变量。
局部变量没有默认值，是刻意为之
成员变量（字段）声明后会自动获得默认值（int 是 0，Object 是 null），但局部变量不会。这不是遗漏，是主动放弃“隐式兜底”：
- 栈帧复用频繁，旧数据残留风险高；直接读取可能拿到上一次方法调用留下的任意字节
- 自动赋默认值会掩盖逻辑漏洞，比如本该由业务规则决定的初始状态，被悄悄设为 0 反而让错误延迟暴露
- 编译期就能卡住问题，比运行时抛 NullPointerException 或计算出荒谬结果更早、更可控
编译器只认路径覆盖，不猜你的逻辑
它不做运行时推测，只做静态路径扫描。哪怕你写的是 if (true) { x = 1; }，只要语法上存在“不走这个分支”的可能性（比如条件是变量而非字面量），它就认为 x 可能未赋值。
- 并列 if 而非 if-else if-else：中间有空档或浮点边界缝隙，变量可能全程跳过所有赋值
- try 块内赋值，却在 try-catch 外读取：异常一抛，变量根本没机会初始化
- switch 缺少 default，或 case 没覆盖全部枚举值：输入意外时无赋值路径
修复不是“选一种”，而是按语义选最稳的
两种主流方式本质不同，适用场景也不同：
-
声明即初始化（如
String name = "";、double total = 0.0;）：适合变量有自然中性初值的场景，消除不确定性最直接 - 强制路径全覆盖（改用 if-else if-else 链、catch 中补默认值或 rethrow、switch 加 default）：适合变量初始值依赖业务上下文，不能随便设“占位值”的情况
背后是 Java 的沙箱哲学
不让局部变量“侥幸可用”，本质是在构建可推演、可协作、可优化的代码基底：
- 读者看到
System.out.println(x)，就能确信 x 之前一定被某处逻辑赋予了明确含义 - 静态分析工具、IDE 提示、JIT 编译器都能基于“已确定赋值”做更激进的优化和检查
- lambda 表达式捕获 final 局部变量时，这种确定性更是线程安全的前提
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
