异常中需对可变对象做防御性拷贝，否则外部修改会破坏内部状态；构造器中用new Date()、Arrays.copyOf()等拷贝入参，getter中返回新副本，避免toString()触发副作用。
抛出异常时如果直接把内部可变对象（比如 Date、ArrayList、数组或自定义可变类）作为异常字段或消息组成部分传出去，就等于把类的内部状态“借出去”了——外部代码可能修改它，进而悄悄破坏你本已封装好的逻辑状态。这不是危言耸听，而是真实存在的表示泄露风险。
为什么异常里也要做防御性拷贝
异常对象常被当作“上下文快照”来使用，尤其是自定义异常中携带业务数据时。但一旦这个数据是可变的，且你只是赋值引用而非复制内容，调用方拿到异常后就能：
- 调用
date.setYear(2099)改变你原始时间字段 - 对
exception.getDetails()返回的List执行add()或clear() - 修改
byte[] payload数组里的字节，影响后续日志还原或审计一致性
构造异常时对入参做防御性拷贝
在自定义异常的构造器里，凡是接收外部传入的可变类型，都必须立即拷贝：
-
Date 类型：用
new Date(original.getTime())，别用original.clone()（已过时且不安全） -
数组：用
Arrays.copyOf(arr, arr.length)或arr.clone() -
Collection/Map：用
new ArrayList(list)、new HashMap(map)；若元素本身可变，还需逐层深拷贝 -
自定义可变类：确保它提供
copy()或带拷贝逻辑的构造器，并在异常构造中显式调用
getter 方法中返回异常字段时再防护一次
即使构造时做了拷贝，如果异常类对外暴露了 getter，也得守住最后一道门：
- 不要写
public Date getTimestamp() { return timestamp; } - 应写成
public Date getTimestamp() { return timestamp == null ? null : new Date(timestamp.getTime()); } - 对集合字段，返回
Collections.unmodifiableList(new ArrayList(details))，或干脆只返回不可变副本
避免在异常消息中拼接敏感可变对象的 toString()
像 new IllegalArgumentException("Failed on " + userConfig) 这种写法很危险——如果 userConfig.toString() 内部会触发状态变更（比如懒加载、计数器递增），或返回的是动态生成的可变结构，就会污染异常语义。更稳妥的做法是：
- 提前提取关键不可变字段：如
userConfig.getId()、userConfig.getName() - 用日志框架记录完整对象（如 SLF4J 的
logger.warn("...", userConfig)），由框架决定是否序列化 - 若必须包含摘要，先做防御性拷贝再调用
toString()
