object.clone() 默认是浅拷贝，只复制基本类型和string，引用类型共享地址；深拷贝需手动递归克隆或序列化反序列化，且cloneable仅为标记接口。
为什么 clone() 总是改一个，另一个也跟着变？
因为 Object.clone() 默认就是浅拷贝 —— 它只复制对象本身字段的值，对引用类型（比如 Teacher、Money、Address）只拷贝内存地址，不新建对象。所以原始对象和克隆对象共享同一份引用数据。
常见错误现象：
• 修改克隆对象里某个 teacher.name，原对象的 teacher.name 也变了
• person1.money.m = 13.6 后，person2.money.m 变成 13.6 而不是保持 99.99
- 基本类型（
int、double等）和String是安全的：改克隆体不影响原对象 - 所有自定义类、数组、集合、包装类以外的引用类型，默认都不安全
- 别指望
super.clone()自动帮你深拷贝 —— 它连Cloneable都不检查，只靠你手动加接口才放行
怎么用 Cloneable 接口写出可用的浅拷贝？
Cloneable 不是工具，它只是一个“许可证”：告诉 JVM “我允许被克隆”，否则调用 clone() 就抛 CloneNotSupportedException。它没方法、不参与逻辑，纯标记接口。
- 必须实现
Cloneable，否则编译不报错但运行必炸 -
clone()方法在Object中是protected，子类必须重写并设为public - 返回值要强制转型，因为
super.clone()返回的是Object
实操示例：
class Student implements Cloneable {
private int id;
private String name;
private Teacher teacher;
@Override
public Object clone() throws CloneNotSupportedException {
return super.clone(); // 浅拷贝：teacher 字段仍指向同一实例
}
}
怎样真正实现深拷贝？两种靠谱路径
深拷贝的本质是：让每个引用字段都指向“新造出来”的对象，而不是复用旧地址。没有银弹，只有两条主流路径，选哪条取决于你的约束条件。
-
手动递归克隆：每个引用字段对应的类也要实现
Cloneable，并在本类clone()中显式调用其clone()
→ 适合结构稳定、可控的 DTO 或内部模型
→ 缺点：字段一多就容易漏写，嵌套深时代码冗长 -
序列化反序列化：把对象写成字节流再读回来，天然生成全新对象图
→ 要求所有涉及类都实现Serializable
→ 注意：含transient字段、静态变量、不可序列化资源（如Thread、Socket）会丢失或报错
手动深拷贝片段示意：
@Override
public Object clone() throws CloneNotSupportedException {
Student copy = (Student) super.clone();
if (this.teacher != null) {
copy.teacher = (Teacher) this.teacher.clone(); // 假设 Teacher 也实现了 Cloneable
}
return copy;
}
哪些情况千万别用 clone()？
不是所有对象都适合走 Cloneable 这条路。有些场景下它反而引入隐蔽风险，甚至根本走不通。
- 类有 final 字段且依赖构造器赋值 →
super.clone()无法绕过 final 限制，会编译失败或字段为默认值 - 父类没实现
Cloneable或没公开clone()→ 子类重写也白搭，super.clone()仍抛异常 - 用了 Lombok 的
@Data或@AllArgsConstructor→ 它不会自动帮你处理引用字段的深拷贝逻辑 - 框架管理的对象（如 Spring Bean、MyBatis 的代理对象）→ 可能被增强、代理，
clone()行为不可控，极易出错
真正麻烦的从来不是“怎么写 clone”，而是“谁来保证所有嵌套层级的 clone 都正确、及时、不漏”。一旦对象图里出现循环引用、第三方类没实现 Cloneable、或某字段是 java.time.LocalDateTime 这种不可变但未实现克隆的类 —— 就得立刻换方案。
