Java变量初始值必须结合业务逻辑选择有含义、可解释、不误导的起点，避免默认值引发空指针、语义模糊或状态错乱；局部变量须显式初始化，成员变量应主动设为业务明确的初始态，final变量初始值即稳定契约。
Java变量初始值不能靠默认值凑合，得结合业务逻辑选一个“有含义、可解释、不误导”的起点。选错初始值，轻则埋下空指针或0值误判隐患，重则导致状态错乱、统计偏差甚至资损。
局部变量：必须显式初始化，且初始值要有业务语义
方法内声明的变量没有默认值，编译器强制要求使用前赋值。但更关键的是——赋什么值？
- 避免用0或null硬编码兜底：比如
int discount = 0;，用户没设置折扣时是“无折扣”还是“折扣为0%”？语义模糊 - 优先用业务可读的默认值：如
OrderStatus status = OrderStatus.PENDING;，比status = null或status = 0更明确 - 条件分支多时，统一在声明处用三元表达式初始化：
String remark = isValid ? "校验通过" : "待补资料"; - 循环计数器建议从
0开始（符合数组索引习惯），但累计金额类变量建议初始化为BigDecimal.ZERO而非0.0
成员变量：默认值是JVM保障，不是业务逻辑依据
字段虽有0、false、null等默认值，但这些值本身不含业务意义，直接依赖会掩盖设计缺陷。
-
List<Item> items;→ 后续调用items.add()必然NPE；应写成List<Item> items = new ArrayList<>(); - 布尔字段慎用
boolean active;：未显式赋值时为false，但“未激活”和“明确禁用”可能含义不同；建议用包装类型Boolean active;并设为null表示“状态未设定” - 金额、时间等敏感字段，推荐用不可变对象+明确初始态：
LocalDateTime createdAt = LocalDateTime.now();或Money amount = Money.zero(); - 构造器中集中初始化，比分散在字段声明处更易维护，尤其当初始化逻辑涉及参数校验或转换时
边界值驱动的初始值设计
初始值本质上是业务规则的第一个落点，应与输入/输出边界对齐，而非随意取中间值。
立即学习“Java免费学习笔记（深入）”；
- 价格字段若业务要求≥0.01元，则初始值不应设为
0.0（非法），而应设为0.01或抛出异常提示缺失 - 分页参数
int page = 1;比page = 0更合理——第1页是合法起点，0页需拦截处理 - 状态机字段初始值必须是合法起始状态：如订单状态机中
OrderState state = OrderState.CREATED;，而非OrderState.CONFIRMED - 枚举字段禁止用
null占位，应定义一个UNKNOWN或UNINITIALIZED枚举项作为显式初始态
final变量：初始值即契约，必须一次到位且可验证
final字段的初始值不是“随便填个数”，而是对外暴露的稳定契约，必须满足可追溯、不可绕过、业务可信。
- 静态常量如
public static final int MAX_RETRY = 3;，数字3需有文档依据（如SLA协议要求） - 实例final字段若依赖构造参数，应在每个构造器中显式赋值，避免漏初始化；IDE可开启“Missing @NonNull annotation”检查辅助发现
- 避免在初始化表达式中调用可能被重写的方法——子类字段尚未初始化，容易返回默认值造成逻辑错乱
- 复杂对象final字段建议用Builder模式封装初始化过程，确保所有必填字段都被赋值且校验通过
