17370845950

不该从零写ArrayUtils，因JDK的Arrays已覆盖多数需求；自行封装易重复造轮子、引发边界错误或类型安全漏洞，且难以正确处理null比较、泛型数组创建及基本类型兼容性问题。

Java 中不需要专门封装“数组工具类”来解决日常问题——JDK 自带的 java.util.Arrays 已覆盖绝大多数需求，自行封装容易重复造轮子、引入边界错误或类型安全漏洞。

为什么不该从零写 ArrayUtils？

多数人想封装数组工具类，是为了解决 null 安全、类型转换、查找、复制等操作。但：

• Arrays.asList() 虽返回 List，但底层是固定长度的包装，误调用 add() 会抛 UnsupportedOperationException；这不是你封装就能绕开的问题，而是要理解其设计意图
• Arrays.copyOf() 和 System.arraycopy() 在性能和语义上已有明确分工：前者自动处理泛型擦除后的类型检查（如 String[] 复制），后者纯底层拷贝、无泛型支持
• 自己写 indexOf(Object[], Object) 很容易忽略 null 元素比较（应使用 Objects.equals(a, b)，而非 == 或 a.equals(b)）

哪些场景真值得封装？

仅当出现 JDK 不支持、且项目高频使用的特定逻辑时

• 对 int[] 执行滑动窗口求和，并缓存前缀和 —— 这属于业务建模，不是通用数组操作
• 将 Object[] 按指定字段（如 getName()）投影为 String[]，且该字段可能为 null（需统一转空字符串）
• 批量校验 String[] 是否全非空、去重并按长度排序 —— 这已超出 Arrays 职责，适合封装为 StringArrayValidator 类

这类封装应聚焦单一职责，命名体现用途（如 NonEmptyStringArray），而非笼统叫 ArrayUtils。

如果非要封装，必须绕开的三个坑

自行封装数组工具方法时，以下三点不处理，大概率在运行时出错：

• 泛型数组创建：不能写 (T[]) new Object[n] 并直接返回 —— 会在调用方触发 ClassCastException；正确做法是要求传入 Class 或改用 List 返回
• 基本类型数组（int[], double[]）无法与 Object[] 统一处理；不要试图用一个 arrayToString(Object[]) 去兼容它们 —— Arrays.toString(int[]) 是重载方法，不是多态
• 修改原数组还是返回新数组？Arrays.sort() 是就地排序，Arrays.stream().sorted().toArray() 是新建；你的方法签名必须明确体现这一点，否则使用者无法预期副作用

真正难的不是写几个静态方法，而是判断某个操作是否该属于“数组工具”范畴——大多数时候，它应该属于领域对象的一部分，或者用 Stream / Guava / Apache Commons 的现成方案更稳妥。