浅拷贝仅复制数组容器及元素引用地址，新旧数组共享对象实例；深拷贝则递归复制所有嵌套对象，完全隔离内存，性能开销大得多。
浅拷贝 vs 深拷贝：先分清你要什么
对象数组（如 List<User> 或 User[]）的“拷贝”常被默认理解为深拷贝，但多数场景其实只需浅拷贝：
-
浅拷贝：只复制数组容器本身 + 元素引用地址，原数组和副本共享同一组对象实例。例如
new ArrayList<>(list)、Arrays.copyOf()、list.toArray()—— 耗时通常 -
深拷贝：不仅要复制数组，还要为每个对象创建全新实例，并递归复制其所有可变字段（如嵌套的
Address、Date）。这必然触发构造、反射、类型判断、甚至 GC 压力，耗时跃升至几十毫秒甚至秒级。
主流深拷贝方式性能排序（10万次，JDK 17+）
当确实需要深拷贝时，效率差距显著：
- 手动 get/set（最快）：≈10–15 ms。无反射、无中间对象，直接字段赋值。适合字段稳定、数量适中的 POJO。
- Cglib BeanCopier（推荐平衡点）：≈25–40 ms。首次生成字节码后复用，运行期接近手写效率，代码简洁，支持跨类拷贝。
- Spring BeanUtils.copyProperties：≈300–500 ms。基于反射+缓存，通用性强但开销大，尤其字段多或含泛型时更慢。
- Jackson 序列化/反序列化：≈1200–2000 ms。涉及 JSON 字符串编解码、临时对象创建、类型推断，适合调试或跨进程，不适合高频拷贝。
容易被忽略的性能陷阱
很多“高耗时”不是拷贝本身导致的，而是周边操作放大了开销：
-
未预热或未固定堆内存：JIT 编译、GC 干扰会让首次运行结果失真；建议用 JMH，加
-Xms512m -Xmx512m和充分 warmup。 -
误把“半拷贝”当深拷贝测：比如 BeanCopier 设置
useConverter = false且未处理Date字段，实际只是浅拷贝，结果不能代表深拷贝能力。 - 集合拷贝混入业务逻辑：测试中若在循环内做数据库查询、日志打印等，会掩盖真实拷贝耗时，应剥离无关操作。
- 忽略对象状态一致性：多个测试轮次使用不同原始对象，字段值、引用关系不一致，会导致对比失效；务必复用同一 source 实例。
实用建议：按场景选方案
不必追求“一种通吃”，根据实际约束快速决策：
- 字段少、结构稳、性能敏感 → 手动 get/set 或 Lombok
@Builder(toBuilder = true)+toBuilder().build() - 需跨模块/跨 DTO 类型、团队维护性优先 → 封装 Cglib BeanCopier 工具类（带 Class 缓存）
- 仅需隔离顶层引用、内部对象只读 → 浅拷贝 + 关键字段单独 new（如
b.setConfig(a.getConfig().clone())） - 配置类、初始化数据、非高频路径 → Jackson 或 Gson，胜在开发快、不易出错
