应使用卫语句提前拦截null而非重复判断，jdk版本决定switch用法，布尔条件直接用if(flag)避免冗余和空指针，嵌套过深需拆分职责或改用策略模式。
if-else 链里重复写 obj != null 是典型冗余
很多人在判断对象属性前，每层都加一遍 obj != null，结果代码又长又容易漏。这不是防御性编程，是条件爆炸的前兆。
真正该做的是提前拦截：用卫语句（guard clause）把 null 情况在开头统一挡掉。
- 场景：处理
User对象的getProfile().getAddress().getCity() - 错误写法：每级都套
if (user != null && user.getProfile() != null && ...) - 正确做法：先
if (user == null) return;，后续直接放心用链式调用（或配合Optional） - 注意：
Objects.requireNonNull()适合参数校验，但别在业务逻辑深处滥用——它抛异常，不是流程控制
用 switch 替代长 if-else if 时要注意 JDK 版本
JDK 14+ 的 switch 表达式支持箭头语法和返回值，但老项目若还在用 JDK 8，硬搬 case "a" -> "x" 会编译失败。
更隐蔽的问题是字符串 switch 在 JDK 7 才引入，之前只能靠 if-else 或 Map<string runnable></string> 模拟。
立即学习“Java免费学习笔记（深入）”；
- JDK 8 及以下：用
if-else或预构建Map，避免反射式字符串匹配 - JDK 14+：优先用
switch表达式，->分支不穿透，不用写break - 性能差异不大，但可读性提升明显；不过
switch对null直接抛NullPointerException，得自己兜底
if (flag == true) 和 if (flag) 看似一样，实际影响可读性和潜在 bug
布尔变量名本身就应该表达状态（如 isReady、hasPermission），再写 == true 不仅啰嗦，还暴露了对类型安全的不信任。
更麻烦的是，如果某天这个变量被改成 Boolean 包装类，== true 在 null 时会抛 NullPointerException，而 if (flag) 会直接 NPE，但至少不掩盖意图。
- 永远用
if (flag)或if (!flag)，别比值 - 如果变量是
Boolean且可能为null，明确处理三态：if (Objects.equals(flag, Boolean.TRUE)) - IDE 警告
Comparison of Boolean expressions using == or !=别忽略——它真在帮你防坑
嵌套过深的 if-else 往往意味着职责没拆开
超过三层缩进的 if-else 链，基本可以判定：这段逻辑不该在一个方法里完成。不是语法问题，是设计信号。
比如权限校验 + 状态检查 + 时间窗口判断 + 外部服务响应合并写在一个方法里，改一处就怕崩三处。
- 优先提取成小方法，命名体现意图：
canAccessResource()、isWithinValidTimeWindow() - 用策略模式替代分支：不同状态对应不同
Handler实现，if-else只剩一层路由逻辑 - 别迷信“扁平化”：强行把嵌套压成一长串
&&并不更好，可读性反而下降，调试也更难定位哪一环失败
多层 if-else 最难 debug 的地方，往往不是条件写错，而是某个中间判断悄悄改变了共享状态，而你根本没意识到它有副作用。
