Arrays.copyOf()和clone()都只做浅拷贝，即复制数组引用而非对象实例；二者性能相近，但clone()略快且可读性差；深拷贝需手动遍历构造或谨慎使用序列化。
Java里Arrays.copyOf()和clone()到底谁在做浅拷贝
两者都只做浅拷贝——对象数组里的元素引用不会被复制，只是把引用值复制了一份。比如你有一个String[]，没问题；但如果是Person[]，新数组和原数组指向的是同一组Person实例。
常见错误现象：newArray[0].setName("xxx")之后，originalArray[0]的名字也变了。
-
Arrays.copyOf(arr, len)会创建新数组，长度可变，底层调用System.arraycopy() -
arr.clone()返回同类型新数组，长度固定为原长，是Object类定义的方法，所有数组都支持 - 性能上差异极小，
clone()略快（少一次方法分派），但可读性差，容易让人误以为它“更彻底”
需要深拷贝时，别碰Serializable序列化方案
用ObjectOutputStream写到ByteArrayOutputStream再反序列化，听起来通用，实际踩坑率极高：类必须实现Serializable、所有字段也要可序列化、transient字段丢失、有static或final引用时行为难预测、性能差（尤其大数组）。
真实使用场景：只有当你明确知道整个对象图结构简单、稳定、且已全面打标Serializable，才考虑它。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 更稳妥的做法是手动遍历+构造：对每个
Person元素调用new Person(p.getName(), p.getAge()) - 如果用Lombok，加
@Builder或@With能省点事；用MapStruct之类代码生成器也行，但引入新依赖要权衡 - 注意嵌套集合：比如
Person里有个List<address></address>，不递归处理，照样是浅的
System.arraycopy()不是万能搬运工，参数错一位就ArrayIndexOutOfBoundsException
它不校验源数组和目标数组的类型兼容性，只认内存块搬移。一旦srcPos + length > src.length或destPos + length > dest.length，立刻抛异常。
典型误用：把length写成arr.length + 1，或者混淆了起始索引（比如从1开始复制却没预留空间）。
- 务必确保：
srcPos ≥ 0、destPos ≥ 0、length ≥ 0、srcPos + length ≤ src.length、destPos + length ≤ dest.length - 复制整个数组常用写法：
System.arraycopy(src, 0, dest, 0, src.length)，别省略0——显式比隐含更可靠 - 它不适用于基本类型和引用类型的混拷（比如
int[]往Object[]拷），编译直接报错
泛型数组根本不能直接创建，new T[n]会编译失败
这是Java类型擦除导致的硬限制。你想写T[] copy = new T[original.length]？编译器会告诉你“generic array creation”。
所以工具方法如Arrays.copyOf(T[] original, int newLength)内部其实是用(T[]) new Object[newLength]绕过去的——靠的是unchecked cast，调用方需自行保证类型安全。
- 自己写泛型数组拷贝方法时，要么接受
Class<t></t>参数来构造（Array.newInstance(componentType, length)），要么用Object[]中转再强转 - 用
ArrayList<t></t>替代数组，能避开大部分泛型数组问题，除非你在写底层工具类或受性能/内存布局约束 - IDE常把
(T[]) new Object[n]标黄警告，这不是bug，是Java机制使然，只要上下文可控，可以加@SuppressWarnings("unchecked")
深拷贝从来不是“选个API就完事”的事，关键在厘清对象图边界——你真需要复制到第几层？哪几个字段允许共享？漏掉一个final List或一个缓存Map，结果就不可控。
