不该从零写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。
立即学习“Java免费学习笔记（深入）”；
如果非要封装，必须绕开的三个坑
自行封装数组工具方法时，以下三点不处理，大概率在运行时出错：
- 泛型数组创建：不能写
(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 的现成方案更稳妥。
