getItems() 返回原始引用导致内部状态被篡改，因Java集合默认不拷贝、final仅锁引用不锁内容；安全做法是返回不可变视图或独立副本。
为什么 getItems() 返回的 List 被调用方一改，内部状态就乱了
因为返回的是原始引用，不是副本。Java 中集合类（如 ArrayList、HashSet）默认不自动拷贝，return items; 就是把堆里那个对象的地址直接交出去了。
常见错误现象：myObj.getItems().add("hacked"); 后，myObj 内部的 items 真的多了一项；或者外部调用 clear() 导致业务逻辑崩掉。
- 只要方法签名返回的是可变集合类型（
List、Set、Map），且没做隔离，就存在风险 - 即使字段声明为
private final List<string> items;</string>，final 只锁住引用，不锁住内容 - 别依赖文档说“请勿修改”，生产环境没人看文档，只看 IDE 自动补全出来的
add()
怎么写一个真正安全的 getItems()
核心原则：返回不可变视图或独立副本。选哪种取决于性能和语义需求。
使用场景：如果集合不大（
- 返回新副本（防御性拷贝）：
return new ArrayList(this.items);—— 安全，但每次调用都新建对象，注意 GC 压力 - 返回不可变视图（JDK 10+）：
return List.copyOf(this.items);—— 零拷贝，但返回的是ImmutableList，任何修改操作会抛UnsupportedOperationException - 旧 JDK（如 8）可用
Collections.unmodifiableList(this.items)—— 注意：它只是加了运行时检查，底层仍是原集合，若原集合被其他路径修改，视图会同步反映变化（不彻底安全）
addAll() 或构造器传入集合时，要不要也拷贝
要。防御性拷贝不是只防 getter，所有“接收外部集合并存为成员”的入口都得拦住。
参数差异：public void setItems(List<string> input) { this.items = new ArrayList(input); }</string> 和 this.items = input; 看似只差一行，实则安全等级天壤之别。
- 构造器里直接
this.items = items;是高危写法，外部传进来的ArrayList一旦被缓存或复用，等于开了后门 - 用
addAll()批量添加？先确认传入的是副本还是原始引用 —— 如果来源是request.getParams()这种框架返回的集合，大概率也是裸引用 - Spring MVC 的
@RequestBody解析出的List默认可变，别直接塞进领域对象字段
泛型擦除会让 unmodifiableList 失效吗
不会。泛型只在编译期起作用，Collections.unmodifiableList 的运行时行为与泛型无关，它拦截的是 add()、remove() 等方法调用，不是类型检查。
容易踩的坑：有人以为用 List<string></string> 声明 + unmodifiableList 就万无一失，结果在别的地方写了 ((ArrayList) items).add(123); —— 强转绕过了泛型，也绕过了不可变包装的代理层（因为 unmodifiableList 返回的是装饰器对象，强转成原始实现类就脱钩了）。
- 永远不要对不可变包装结果做强制类型转换
- 如果真需要运行时类型安全，配合
instanceof检查 + 明确拒绝非预期类型，而不是靠泛型幻想 - 最稳的路：统一用副本（
new ArrayList(input)），哪怕多占点内存，也比追查“谁偷偷改了集合”强
真正的难点不在怎么写那行 new ArrayList，而在于意识到：每个接收或返回集合的地方，都是潜在的共享内存区域。没人会故意破坏，但并发、复用、误用，三者叠加起来，比空指针还难复现。
