重写 clone() 仍为浅拷贝，因 Object.clone() 仅复制字段值，对引用类型不递归拷贝；需手动深拷贝可变引用字段，否则修改副本会影响原对象。
为什么重写 clone() 很容易还是浅拷贝
因为默认的 Object.clone() 只复制对象本身字段，对引用类型字段不做递归复制——哪怕你加了 implements Cloneable，也只解除了抛异常的限制，不改变复制行为。
常见错误现象：clone() 后修改副本里的集合或嵌套对象，原对象跟着变；或者两个对象的 hashCode() 一样但 equals() 返回 false，说明内部引用没断开。
- 必须手动对每个可变引用字段调用其自身的
clone()或新建副本（比如用new ArrayList(originalList)） - 如果字段是第三方类且没实现
Cloneable，不能直接调field.clone()，得用构造器、静态工厂或序列化等替代方案 - 注意循环引用：A 引用 B，B 又引用 A，手动深拷贝时容易栈溢出或无限递归
如何安全地在 Java 中重写 clone()
核心原则：所有可变的引用字段，必须显式深拷贝；基本类型和不可变类（如 String、LocalDateTime）可直接赋值。
使用场景：需要快速创建独立副本、且对象结构相对稳定（字段不多、嵌套不深），又不想引入额外依赖（如 Apache Commons Lang）。
立即学习“Java免费学习笔记（深入）”；
- 声明类为
implements Cloneable，否则super.clone()会抛CloneNotSupportedException - 重写方法签名必须是
public Object clone()，返回类型不能窄化为子类（Java 5+ 支持协变返回，但底层仍需强转） - 调用
super.clone()获取原始字段副本，再逐个替换引用字段为深拷贝结果 - 如果字段是数组，
Arrays.copyOf()或clone()数组本身是浅的，元素仍是原引用——需遍历处理每个元素
public class Person implements Cloneable {
private String name;
private List<String> hobbies;
@Override
public Object clone() throws CloneNotSupportedException {
Person cloned = (Person) super.clone();
cloned.hobbies = new ArrayList<>(this.hobbies); // 深拷贝 List
return cloned;
}
}
比重写 clone() 更可靠的选择有哪些
因为 clone() 机制本身有设计缺陷（违反构造逻辑、类型不安全、与 final 字段冲突），多数现代项目倾向避开它。
性能/兼容性影响：序列化深拷贝慢且要求所有字段可序列化；构造器方式清晰但字段多时冗长；Lombok 的 @Builder(toBuilder = true) 生成的 toBuilder().build() 是浅拷贝，不能直接用。
- 用拷贝构造器（copy constructor）：明确、可控、支持泛型和 final 字段，例如
new Person(original) - 用静态工厂方法：如
Person.copyOf(original)，便于后续扩展校验或转换逻辑 - 必要时用 JSON 序列化反序列化（如 Jackson 的
readValue(writeValueAsBytes(obj), type)），但要注意 transient 字段丢失、日期格式、自定义序列化器缺失等问题
哪些情况根本不能靠 clone() 解决
不是所有“复制”需求都适合走 clone() 路线，尤其当对象状态依赖外部资源或运行时上下文时。
容易踩的坑：以为重写了 clone() 就一劳永逸，结果在并发环境下因未同步共享缓存字段而出错；或忽略了代理对象（如 Hibernate 的懒加载实体）、持有线程局部变量的对象。
- 对象包含
ThreadLocal、Socket、Connection等资源句柄——复制无意义，应重新初始化 - 使用了 CGLIB 或 JDK 动态代理的对象，
clone()会丢失代理逻辑，得到的是裸对象 - 字段含 lambda 表达式或方法引用：它们可能捕获了外部对象，深拷贝无法自动重建这种闭包关系
复杂点在于，深拷贝从来不只是“复制字段”，而是“重建语义等价的独立实例”。一旦对象图里混入不可控状态、外部依赖或动态行为，就得按具体场景设计复制策略，而不是指望一个通用 clone() 方法兜底。
