java变量初始化必须匹配业务逻辑：局部变量需每条路径赋值，成员变量应避免默认值陷阱，静态内容须考虑线程安全与加载时机，继承中构造器不可调用可重写方法。
Java变量初始化不是填空题，而是业务逻辑的起点。它必须和真实场景对齐——比如账户余额不能默认为0而应明确为“未开通”，列表不能留null而应初始化为空集合。初始化错一步，后续所有业务判断都可能跑偏。
局部变量：每条路径都得有明确初始值
方法内部的变量没默认值，编译器会逐路径检查是否被赋值。靠“反正后面总会赋值”这种想法很容易翻车。
- 避免分支遗漏：if/else、try/catch中所有出口都要覆盖初始化，否则编译不通过
- 推荐声明即赋值：int retryCount = 3; String status = "pending"; 这样语义清晰，也不用担心漏掉某条执行流
- 复杂逻辑拆到方法里：比如需要查配置决定初始值，就写成 getStatusFromConfig()，而不是在if里堆判断逻辑
成员变量：默认值是安全垫，不是业务值
private List
- 引用类型优先初始化为空容器：private List
orders = new ArrayList(); - 数值型字段慎用0：balance = 0 可能掩盖“未开户”状态，改用 Optional
或单独 boolean isActivated 更准确 - 配置类字段建议用构造器统一注入：避免字段间隐式依赖，也方便单元测试替换值
静态内容：一次初始化，终身生效，得想清楚
static final API_URL = "https://api.example.com/v2"; 没问题；但 static Map cache = loadFromDB(); 就得掂量——这个加载时机是否可控？失败了怎么兜底？
- 静态常量用 static final + 大写命名，声明时直接赋值
- 需计算或IO的静态资源，改用静态块+异常捕获，或延迟初始化（如 Holder 模式）
- 多线程环境注意：静态块只执行一次，但里面初始化的对象未必线程安全，比如 SimpleDateFormat 就不能放静态变量里
继承场景：父类字段先活，子类逻辑后到
new Child() 时，Parent 的字段和实例块先跑完，Child 的字段才开始初始化。如果 Parent 构造器里调用了被子类重写的方法，而该方法访问了子类尚未初始化的字段，结果就是 0 或 null。
- 构造器里只做必要赋值，别调用可重写方法
- 字段依赖关系尽量扁平化：避免 fieldA = compute(fieldB)，而 fieldB 在后面才声明
- 复杂初始化逻辑移到 init() 方法，由上层显式调用，时机更可控
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
