Java流程控制的逻辑死角是理论不会发生但实际常出现的分支遗漏，如if无else、switch缺default、循环越界、异常路径未覆盖、null/空集合遍历等，须通过显式收口、防御性校验和结构化设计全面堵漏。
Java 流程控制中的逻辑死角，本质是那些“理论上不会发生、实际上却常出现”的分支遗漏点。比如 if 分支没写 else、switch 缺少 default、循环边界判断错位、异常路径未覆盖、null 或空集合被直接遍历等。防御性编程不是加一堆 if-else，而是用结构化手段提前堵住这些隐性缺口。
所有分支必须显式收口
流程控制最典型的死角，就是“以为只有一种情况，结果漏了其他可能”。Java 不强制要求 if 必须有 else、switch 必须有 default，但生产代码必须做到：
- 每个 if 都要配 else（哪怕只是 throw new IllegalStateException("未覆盖的业务状态：" + status)）
- 每个 switch 都必须有 default 分支，且不能是空语句；建议统一抛出 IllegalArgumentException 或返回兜底值
- 枚举类型 switch 要配合 @SuppressWarnings("all") + 注释说明“已穷举”，并配合单元测试覆盖全部枚举值
- 布尔表达式避免嵌套过深，复杂条件优先提取为命名方法（如 isEligibleForPromotion()），内部逻辑更易校验和覆盖
循环与边界条件必须主动设防
for / while 循环是 NPE 和数组越界高发区，尤其在处理外部输入或动态集合时：
- 遍历前必判空/非空：if (CollectionUtils.isEmpty(list)) { return; }，绝不假设 list 一定有元素
- 下标访问前必校验长度：if (i >= 0 && i
- while 循环要有明确退出条件，避免死循环；建议配合计数器或超时机制（如重试次数 > 3 则 break）
- Stream 操作慎用 get()、orElseThrow() 等危险方法；优先用 orElse(null) + 后续判空，或封装为 Optional 安全链式调用
异常路径必须纳入主流程设计
很多逻辑死角出现在 try-catch 外围——开发者只关注“成功走通”，却忽略“失败后程序是否还能继续安全运行”：
立即学习“Java免费学习笔记（深入）”；
- catch 块里不能只打日志就完事，必须明确后续行为：是返回默认值？降级响应？还是重新抛出带上下文的新异常？
- finally 中避免修改业务状态或抛新异常；资源释放优先用 try-with-resources
- 方法声明 throws 的异常，调用方必须处理——要么捕获并决策，要么向上声明；禁止用 catch (Exception e) {} 吞掉错误
- 对远程调用、文件读写、数据库查询等 I/O 操作，超时、重试、熔断、缓存旧数据这四层策略至少启用两层
空值与非法状态必须从源头拦截
逻辑死角往往始于一个未被察觉的 null 或非法值，随后在多层调用中不断传递、放大：
- 方法入参用 Objects.requireNonNull() 或 @NonNull 注解强制校验，让问题在第一行就暴露
- DAO 层查询结果不返回 null，统一返回 Optional 或空集合；Service 层接收时立刻展开处理
- 状态机类字段（如 order.getStatus()）不用 String 或 int 表示，改用枚举，并在构造/设置时校验合法性
- 关键对象创建后立即断言核心属性：assert user.getId() != null : "用户ID未生成";（上线前可关闭 assert，但开发测试阶段必须开启）
