Object.clone()默认只做浅拷贝，仅复制字段值，对引用类型（包括List<String>、数组等）只拷贝地址，不递归复制其内容，导致原对象与副本共享可变容器，引发并发或数据一致性问题。
Object.clone() 默认只做浅拷贝，连基本类型包装类都可能出问题
很多人以为 Object.clone() 至少能安全复制 String、Integer 这类不可变对象，其实不然——它只是“字段级复制”，不关心语义。只要字段是引用类型，就只拷贝地址。比如一个包含 List<String> 的对象调用 clone()，新对象的 data 字段和原对象指向同一个 ArrayList 实例。
常见错误现象：clonedList.add("new") 后，原对象的列表也多了一项；或者多线程中一个线程清空了列表，另一个线程突然发现数据没了。
关键点在于：不可变性只保护值不被修改，不保护容器本身。而 ArrayList 是可变容器，它的引用被共享了。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远检查你 clone 的类里有没有
Collection、Map、数组、自定义引用类型字段 - 不要依赖
String的不可变性来掩盖引用共享问题 - 如果类里只有基本类型和
String，且确定未来不会加引用字段，clone()才勉强可用
深拷贝必须递归穿透所有引用层级，漏一层就等于没拷贝
所谓“深拷贝”，不是“把当前对象复制一遍”就够了，而是要确保从根对象出发，沿着所有引用字段向下走，每一层都新建实例。比如 Person → Address → City → Region，四层引用，就得新建四个对象。
容易踩的坑：
- 只重写了
Person.clone()，但Address没实现Cloneable或没重写clone()，结果Person是新的，Address还是旧的 - 用
new ArrayList(originalList)复制列表，看似深了，但如果列表里存的是Person对象，这些Person本身没被克隆，还是共享的 - 忽略数组：字段是
Person[]，直接clone()数组只复制引用，不是元素
性能影响明显：对象图越深、越宽（比如含多个集合），序列化方式或手动递归 clone 的耗时越不可控，GC 压力也会陡增。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
序列化实现深拷贝时，Serializable 不是万能通行证
用 ObjectOutputStream + ByteArrayInputStream 做深拷贝，前提是整个对象图上**每个类及其所有字段类型都必须可序列化**。漏一个 transient 字段、一个未实现 Serializable 的内部类、甚至一个 ThreadLocal，都会在 writeObject 阶段直接抛 NotSerializableException。
典型错误信息：java.io.NotSerializableException: java.lang.ThreadLocal，往往是因为某个工具类悄悄持有了 ThreadLocal 实例。
使用场景受限：
- 不能用于含非序列化资源的对象（如文件句柄、数据库连接、Socket）
- 静态字段、
transient字段不会被复制，可能破坏业务逻辑 - 某些框架生成的代理类（如 MyBatis 的 Mapper、Spring AOP 代理）默认不可序列化
别指望加个 implements Serializable 就万事大吉——得逐个确认依赖链上的每个类型是否真正支持序列化语义。
BeanUtils.copyProperties 是浅拷贝，别被名字骗了
BeanUtils.copyProperties(source, target) 看似“复制属性”，实际只是反射读取 source 字段值、再反射写入 target 对应字段。它完全不创建新对象，也不处理嵌套对象。对 source.address 和 target.address，它只是把前者的引用赋给后者——典型的引用拷贝。
常见误用场景：
- 用它做“对象备份”后修改 target，结果 source 数据也被改了
- 在 DTO 转 VO 时，以为用了 copy 就隔离了，实际上两个对象还共用一个
Address实例 - 配合 Lombok 的
@Data使用，字段都是 public 或通过 getter/setter 访问，但 copy 过程中没有任何深度逻辑
它适合的场景仅限于：两个对象结构一致、字段全是基本类型或不可变引用、且你明确接受“共享引用”的副作用。一旦涉及任何可变容器或嵌套对象，就必须换方案。
复杂点在于：很多开发者直到线上出现并发修改异常或脏数据才意识到，自己写的“复制”根本没切断引用链。最隐蔽的坑，往往藏在第三层引用里——你以为只有一层 List，结果 List 里的每个元素又持有一个 Map，而那个 Map 的 value 是个未克隆的业务对象。
