Java中ArrayList.clone()只做浅拷贝，新列表与原列表共享元素引用，修改副本中的自定义对象会影响原列表；修复需手动深拷贝或序列化方案。
Java里用clone()克隆ArrayList，为什么改副本还影响原列表？
因为ArrayList.clone()只做浅拷贝——它新建了一个ArrayList容器，但里面存的元素引用没变。如果元素是自定义对象（比如User），两个列表里的User实例还是同一个对象。
- 现象：修改
list2.get(0).setName("Alice")，list1.get(0)的名字也变了 - 原因：
clone()没递归复制元素，只复制了数组引用本身 - 修复方式：不能只靠
clone()，得手动遍历+深拷贝每个元素，或换序列化方案 - 注意：
Arrays.asList(...).clone()甚至不工作——返回的是不可变视图，clone()抛UnsupportedOperationException
Python中copy.copy()和copy.deepcopy()对嵌套列表的行为差异
copy.copy()只复制外层容器，子列表仍是原引用；copy.deepcopy()才真正断开所有层级的引用链。
- 常见错误：用
ys = copy.copy(xs)处理xs = [[1,2], [3,4]]，然后ys[0].append(99)会导致xs[0]也多出99 - 性能代价：
deepcopy要递归遍历整个对象图，遇到循环引用会报RecursionError，大数据量时明显变慢 - 替代思路：若结构固定（如全是字典/列表），可用
json.loads(json.dumps(obj))快速“伪深拷贝”，但不支持函数、datetime、自定义类等非JSON类型
Spring项目里DTO传参总被意外修改？别只依赖MapStruct的@Mapping
MapStruct默认生成的映射方法是浅拷贝逻辑——源对象字段是引用类型时，目标对象拿到的仍是同一份引用。这在Service层并发调用或事务回滚场景下极易引发数据污染。
- 典型症状：A线程修改了DTO里的
order.getItems()，B线程读到的也是改后的集合 - 解决路径：在
@Mapper接口上加uses = {CollectionMapper.class}，并自定义CollectionMapper对List做new ArrayList(source)或逐项clone() - 更稳妥做法：DTO类自身实现
Serializable，配合工具类SerializationUtils.clone(dto)（来自Spring Core），确保彻底隔离 - 坑点：
SerializationUtils.clone()要求所有嵌套对象都可序列化，否则抛NotSerializableException，需逐级检查
为什么序列化反序列化是“最老实”的深拷贝方案？
它绕过了所有引用共享的可能性——把对象写成字节流再重读，等于强制重建整个对象树，天然切断所有内存地址关联。
- 优势：不依赖对象是否实现
Cloneable，也不关心字段是否private或final，只要可序列化就生效 - 代价：性能开销大（IO+反射）、无法序列化
Thread/Socket等JVM资源类、静态字段和transient字段丢失 - 实用技巧：生产环境慎用
ObjectOutputStream直接序列化，优先选Kryo或FST等高性能替代库，避免java.io的GC压力 - 关键提醒：序列化深拷贝 ≠ 安全深拷贝——若类里有
final字段指向可变对象（如final List<string> tags</string>），反序列化后仍可能被外部修改
