java工具类应追求“用得越少越稳”，objects.equals()防空指针、collections.emptylist()避免误修改、stringutils.isblank()专注无副作用判空，核心是职责收敛与契约明确。
Java 工具类不是“写得越全越好”，而是“用得越少越稳”——JDK 自带的 Objects、Arrays、Collections 等类，本质是把高频边界逻辑下沉为可验证、可复用、不可绕过的标准动作。
为什么 Objects.equals() 要比 a == b || a.equals(b) 更安全
手写空值判断容易漏掉一边为 null 的情况，尤其在链式调用或泛型擦除后，equals() 方法可能抛 NullPointerException。而 Objects.equals() 内部先判空再转发，语义明确且无副作用。
- 常见错误：用
user.getName().equals("admin")前没校验user或getName()返回值 - 正确姿势：
Objects.equals(user != null ? user.getName() : null, "admin")，或更干净地用Optional.ofNullable(user).map(User::getName).filter("admin"::equals).isPresent() - 注意：它不替代语义相等（比如忽略大小写），只是 null-safe 的基础等价判断
Collections.emptyList() 为什么比 new ArrayList() 更适合做返回值
返回新实例会误导调用方以为可以修改，实际却可能破坏封装；而静态空集合是不可变单例，内存零开销，且明确传递“这里真的没有数据”的契约。
- 典型陷阱：接口返回
List<string></string>，内部 new 一个空ArrayList，下游误 add 导致UnsupportedOperationException（如果用了Collections.unmodifiableList包裹）或静默失败（没包） - 性能影响：每次调用
Collections.emptyList()都返回同一个对象，无 GC 压力；而new ArrayList()每次都分配堆空间 - 兼容性提醒：JDK 9+ 推荐优先用
List.of()（不可变）、Set.of()，但它们对 null 元素敏感，Collections.emptyList()仍是最保守选择
别在工具类里塞“万能转换器”：从 StringUtils.isBlank() 看职责收敛
Apache Commons Lang 的 StringUtils.isBlank() 之所以被广泛采纳，不是因为它功能多，而是它把“判定字符串是否为空白”这件事彻底闭环了：null、""、" " 全覆盖，且不尝试转类型、不 trim 后再判、不抛异常。
立即学习“Java免费学习笔记（深入）”；
- 反面例子：自己写的
StringHelper.toSafeString(obj)，内部调用obj.toString()，结果传入null就崩；或者加了自动 trim，导致前端传来的 " x " 和 "x" 被当成等价 - 关键差异：
isBlank()只回答“是否该视为空”，不附带任何副作用；而trim()是另一个独立操作，该不该 trim，由业务决定 - 容易踩的坑：用
StringUtils.isEmpty()替代isBlank()，漏掉纯空格场景，线上查半天才发现搜索关键词输了一串空格也能命中
真正难的不是写出工具方法，而是忍住不加“顺手优化”——比如在 parseDate() 里自动补时区、在 toJson() 里默认忽略 null 字段。这些看似贴心的默认值，最终都会变成调用方无法关闭的隐式行为。
