Arrays.copyOf()语义清晰、自动创建数组、防null误用，适合多数场景；System.arraycopy()性能更高、支持精确偏移复制，但需预分配目标数组且参数易错；clone()浅拷贝陷阱多，已逐步被弃用。
数组拷贝 API 的设计优劣，不在于“有没有方法”，而在于是否让开发者一眼看懂意图、少踩坑、且不为性能妥协可读性。
语义清晰度：意图是否一目了然
好的 API 应该让调用者不用查文档就能猜中用途。比如 [...arr] 直观表达“我要一份新数组”，而 arr.concat() 本意是拼接，用于拷贝反而让人困惑；Array.from(arr) 虽安全，但语义偏向“从类数组构造”，不如展开运算符直白。
Java 中 Arrays.copyOf(arr, len) 比 System.arraycopy() 更易懂——后者要填 5 个参数，稍不注意就索引越界或长度错配；clone() 看似简洁，却隐含“浅拷贝”陷阱，尤其对对象数组，容易误以为已完全隔离。
安全性与默认行为是否合理
API 默认应防错，而非放任出错。structuredClone() 在支持环境下默认处理 Date、Map、循环引用等，比 JSON.parse(JSON.stringify()) 这种“看似能用、实则丢数据”的方式更可靠；它不自动序列化函数或 Promise，但明确报错，而不是静默丢失。
Java 的 Arrays.copyOfRange(arr, from, to) 自动截断越界请求（如 to > arr.length），而 System.arraycopy() 遇到越界直接抛异常——前者更宽容，后者更严格，适用场景不同，但都比手写 for 循环更容易控制边界。
灵活性与约束的平衡
太灵活易误用，太死板难适配。System.arraycopy() 和 C# 的 Array.Copy(五参数版) 允许任意偏移和重叠复制，适合滑动窗口、内存合并等底层操作，但要求目标数组已分配、类型匹配、长度校验全靠人写，容错率低。
相比之下，Arrays.copyOf() 封装了数组创建和复制两步，省去手动 new，降低出错概率；Array.prototype.with()（ES2023）只允许单点更新，看似限制多，但恰恰避免了“先拷贝再改多个位置”这种易错模式，语义精准，JIT 也更容易优化。
兼容性与演进成本
一个好 API 要兼顾当下可用性和未来可替换性。structuredClone() 是现代标准，但旧环境需 polyfill 或降级；JSON 序列化 兼容性极广，代价是语义残缺——它不是“深拷贝 API”，只是“字符串往返模拟”。
Java 的 clone() 方法从 JDK 1 就存在，但因浅拷贝语义模糊、需实现 Cloneable 接口、子类易漏重写，已被许多团队弃用；Arrays.copyOf() 虽晚于 clone()，却因语义明确、无需额外接口、内部复用 arraycopy，成为实际首选。
