正确写法是 if (str == null || str.length() == 0)，先用 == null 快速拦截 null，再用 length() == 0 判断空字符串，语义明确、零依赖、性能优；顺序不可颠倒，避免 null.length() 报错。
Java 中 if 判断字符串为 null 或空字符串的常见错误
直接写 str == null || str.equals("") 看似合理，但一旦 str 是 null，str.equals("") 就会抛出 NullPointerException。这是新手最常踩的坑——把两个条件用 || 连接，却没保证左侧短路判断能真正兜住右侧风险。
根本原因在于 Java 的逻辑或 || 虽然支持短路，但前提是左侧表达式本身不抛异常。而 null.equals(...) 不是“返回 false”，而是直接崩掉。
- 别用
str.equals("")做右侧判断，除非你 100% 确保str != null - 别依赖 IDE 自动补全的
Objects.equals(str, "")来替代判空逻辑——它对null和""都返回true，但语义模糊，容易掩盖真实意图（比如你其实只想过滤掉空值，而非把null当作有效空字符串处理） - 如果项目用了 Apache Commons Lang，
StringUtils.isEmpty(str)是安全且语义清晰的选择；但要注意它把null和""都视为“empty”，不区分二者
推荐写法：用 == null + .length() == 0 组合
这是 JDK 自带、零依赖、语义明确、性能无损的标准解法。核心逻辑是：先用引用比较快速拦截 null，再用轻量级的 .length() 判断是否为空字符串。相比 .equals("")，它不涉及字符数组遍历，也不创建临时对象。
- 正确写法：
if (str == null || str.length() == 0) - 如果还要排除纯空白（如
"\t \n"），改用str == null || str.trim().length() == 0，但注意trim()会新建字符串对象，高频调用需权衡 - 避免写成
str.length() == 0 || str == null——顺序反了，null.length()直接报错 - JDK 11+ 可用
str == null || str.isEmpty()，.isEmpty()比.length() == 0更可读，但效果完全等价
为什么不用 Objects.nonNull(str) && !str.isEmpty()
这写法语法合法，也安全，但多了一层包装调用，且逻辑是“非空且非空”，双重否定不如直述“是空或为空”来得干脆。更重要的是，它在阅读时需要脑内多转一道弯：你得先理解 nonNull 返回 true 才进入后续判断，而原始需求只是“跳过 null 和 empty”。过度封装反而模糊了控制流意图。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
-
Objects.nonNull(str)底层就是str != null，没额外价值 -
!str.isEmpty()和str.length() == 0在功能上等价，但前者是“取反”，后者是“直判”，后者更贴近 if 的原始语义 - 如果团队统一用
Objects工具类，那可以接受；但单独为这个场景引入，属于杀鸡用牛刀
Spring Boot 里 @NotBlank 和 @NotNull 的实际效果差异
这两个注解常被误认为等价于手动判空逻辑，其实它们只在 Bean Validation 触发时起作用（比如 Controller 参数绑定、@Valid 标注处），并不会自动插入到你的 if 语句里。也就是说，加了 @NotBlank 不代表你代码里就可以省掉 if (str == null || str.length() == 0)。
-
@NotNull只校验null，允许"" -
@NotBlank校验null且校验str.trim().length() == 0，即连空白字符串也拦住 - 校验失败抛的是
ConstraintViolationException，不是NullPointerException，错误类型和堆栈位置完全不同 - 别指望注解能帮你“自动修复”业务逻辑里的空值处理——它只负责报错，不负责兜底
真正容易被忽略的是：null 和 empty 在业务语义上往往不同。比如用户没填邮箱（null）和填了空字符串（""）可能代表两种状态，硬塞进同一个 if 分支反而会掩盖问题。
