stringutils是最该先加进java项目的工具类，可省80%空指针判断和字符串胶水代码；判空须分场景选isempty（null/零长）或isblank（含空白字符）；dateutils线程安全但解析能力有限；collectionutils注意apache与spring版本差异；numberutils默认静默失败，应优先用createinteger或iscreatable校验。
StringUtils 是你写 Java 时最该先加进项目的工具类，它能帮你省掉 80% 的空指针判断和字符串胶水代码。
字符串判空为什么不能只用 == null || str.length() == 0
手写判空容易漏掉空白字符（比如 "\t\n "），结果业务逻辑在测试环境正常，上线后因前端多传了空格就抛 NullPointerException 或逻辑错乱。
正确做法是分场景选方法：
-
StringUtils.isEmpty(str)：只检查null和长度为 0（不 trim） -
StringUtils.isBlank(str)：检查null、空、或全为空白字符（isWhitespace()判定） - 永远别对用户输入或 HTTP 参数直接用
str.trim().length() == 0—— 它会新建字符串对象，且没处理null
DateUtils 比 SimpleDateFormat 安全在哪
SimpleDateFormat 不是线程安全的，多个线程共用一个实例大概率触发 java.lang.ArrayIndexOutOfBoundsException 或日期错乱；而 DateUtils 所有方法都是无状态静态调用。
常见误用：
立即学习“Java免费学习笔记（深入）”；
- 把
DateUtils.parseDate("2025-01-01", "yyyy-MM-dd")当成万能解析器 —— 它不支持毫秒、时区缩写（如"CST"），失败直接抛ParseException - 用
DateUtils.addDays(date, n)计算跨月日期时，别假设它会自动处理月末（比如 1 月 31 日 + 1 天 → 2 月 1 日），它确实会，但得确认你用的是lang3而非旧版lang（包名不同，行为有差异）
CollectionUtils 和 Spring 的 CollectionUtils 别混用
两者方法名高度重合，但语义不同：org.apache.commons.collections4.CollectionUtils.isEmpty(null) 返回 true，而 org.springframework.util.CollectionUtils.isEmpty(null) 也返回 true —— 表面看一样，但前者还提供 intersection、disjunction 等集合代数操作，后者没有。
项目里如果同时引入了 Spring 和 Commons Collections，务必注意导入路径：
- 要交集/差集/子集判断 → 用
org.apache.commons.collections4.CollectionUtils - 只是判空或转数组 → 用 Spring 版更轻量，不额外引依赖
- Maven 中若同时存在
commons-collections4和已废弃的commons-collections（v3.x），运行时可能因类加载顺序导致NoClassDefFoundError
NumberUtils 解析数字时的静默失败陷阱
NumberUtils.toInt("abc") 默认返回 0，而不是抛异常。这看起来方便，但会让“参数非法”变成“默认值生效”，掩盖真实问题。
更安全的用法：
- 用
NumberUtils.createInteger(str)：失败时抛NumberFormatException，便于定位源头 - 用
NumberUtils.isCreatable(str)先校验再转，避免静默吞错 -
NumberUtils.toInt(str, -1)可指定默认值，但必须是你业务上明确可接受的兜底值，不是随便填0
lang3 的真正门槛不在 API 多少，而在你是否清楚每个方法的空值策略、线程安全性、以及它和 JDK 原生方法的边界在哪里——比如 StringUtils.join() 不会为 null 元素抛异常，但 String.join() 会。 
