应提取方法而非深层嵌套——三层以上 if 需警觉；优先用卫语句+提前返回，封装校验为 boolean 方法；避免 Boolean 包装类空指针与 == 比较；输入统一用 nextLine()+try-catch 解析。
用 if-else if-else 嵌套还是提取方法？
嵌套三层以上 if 就该警觉了——不是语法错，是可读性和维护性立刻变差。控制台程序虽小，但逻辑一复杂（比如用户输入+状态校验+权限判断+时间窗口检查），嵌套会迅速失控。
实操建议：
- 把每个独立判断条件封装成返回
boolean的私有方法，例如isValidAge(int age)、isWithinTrialPeriod() - 用提前返回替代深层嵌套：先校验前置失败条件，
return或抛IllegalArgumentException，主流程保持扁平 - 避免在条件中直接写复杂表达式，比如
if (user.getRole() != null && user.getRole().equals("ADMIN") && System.currentTimeMillis() - user.getLastLogin() —— 拆成变量或方法更易测、易调
switch 能不能处理字符串和枚举以外的复合条件？
Java 14+ 的 switch 表达式支持 case 多值、箭头语法，但它本质仍是单维度匹配，不支持 age > 18 && status == ACTIVE 这类组合条件。
常见错误现象：硬把布尔表达式塞进 switch，结果写成 switch (true) { case age > 18 && role.equals("USER"): ... } —— 编译不过，且违背设计本意。
立即学习“Java免费学习笔记（深入）”；
实操建议：
-
switch只用于明确的离散值分发，比如用户输入命令"start"、"stop"、"status" - 真要组合多个布尔条件，用策略模式或规则引擎太重，简单项目直接用卫语句 + 提前返回更轻量
- 若条件分支极多且稳定，可考虑用
Map<string runnable></string>映射命令到动作，比长if-else if更易增删
用 Boolean 包装类做条件判断容易踩什么坑？
控制台程序常从 Scanner 或配置读取开关，误用 Boolean.parseBoolean() 后直接判空，或拿 Boolean 对象和 true 用 == 比较，导致 NullPointerException 或逻辑错。
典型错误：
Boolean enabled = config.getEnableFlag(); // 可能为 null
if (enabled == true) { ... } // null 时整个条件为 false，但意图可能是“未配置即禁用”，这就不对实操建议：
- 优先用基本类型
boolean，配置解析层就做兜底：config.getBoolean("enable", false) - 必须处理
Boolean对象时，用Objects.equals(enabled, Boolean.TRUE)或显式判空：enabled != null && enabled - 别依赖
parseBoolean()的宽松行为——它把任何非"true"（忽略大小写）都当false，包括"false"、"no"、""，容易掩盖配置错误
控制台交互中，用户输错怎么让条件逻辑不崩？
控制台程序最常崩在 nextInt() 后跟 nextLine()，或者数字输入用 next() 却没处理非数字输入，导致后续 Scanner 状态混乱，条件判断永远走不到预期分支。
实操建议：
- 统一用
nextLine()读所有输入，再手动解析：Integer.parseInt(input.trim())，并包try-catch处理NumberFormatException - 输入校验逻辑别混在业务条件里，单独抽成
validateInput(String raw)，返回Optional<integer></integer>或自定义结果对象 - 避免用
hasNextInt()判断后再调nextInt()——中间可能被其他线程或信号干扰；不如直接读、解析、捕获异常更可靠
控制台程序的条件逻辑难不在语法，而在输入不可控、状态不持久、调试难定位。越想“省事”写一行长条件，后面修 bug 越花时间。把校验、解析、转换这些脏活拆干净，剩下纯业务条件才真正可控。
