根本原因是 collections.unmodifiablexxx 返回的是只读包装器而非独立副本，调用 add() 等修改方法必然抛出 unsupportedoperationexception；这是设计契约，非 bug。
遇到 UnsupportedOperationException，根本原因不是 Collections 工具类“有问题”，而是它明确设计为返回不可变视图——调用 add() 这类修改方法时，必然失败。这不是 bug，是契约行为。
只读集合的本质是“不可变视图”，不是“深拷贝副本”
Collections.unmodifiableXXX 系列方法（如 unmodifiableList()、unmodifiableSet()）返回的并不是新创建的独立集合，而是对原集合的一个“只读包装器”。它内部持有一个原始集合的引用，所有读操作（get()、contains()、iterator()）委托给底层集合；但所有写操作（add()、remove()、clear()）直接抛出 UnsupportedOperationException。
这意味着：
- 如果原始集合本身被外部其他代码修改了，只读视图会立刻反映出变化（可能引发并发问题）；
- 你无法通过只读视图反向修改原始集合，也无法绕过限制——没有后门；
- 它不阻止你把只读集合赋值给
List或Collection类型变量，但类型擦除和接口多态会让编译期“放行”，运行期才暴露问题。
排查关键点：确认哪里在误调用 add()，而非“修复”只读集合
不要试图 catch 这个异常或重写 add() 方法——那是违背设计意图的错误方向。应定位并修正调用方逻辑：
- 检查调用
add()的代码是否误将Collections.unmodifiableList(...)的返回值当作可变列表使用； - 查看该集合是否由公共 API 返回（如工具类、配置解析器、DTO 构造器），文档是否注明“返回不可修改视图”；
- 搜索项目中类似
return Collections.unmodifiableList(list)的模式，再逆向追踪哪些地方接收了该返回值并尝试修改； - 注意 IDE 提示：IntelliJ 在调用不可变集合的修改方法时会标黄警告（如 “Method call may produce UnsupportedOperationException”），Eclipse 也有类似检查项，别忽略。
正确替代方案：按场景选择真正可变或安全不可变的实现
若业务确实需要增删元素，就该用可变集合；若需确保线程安全或彻底不可变，应选用更健壮的替代品：
- 要可变？直接用
new ArrayList(original)或new LinkedList()创建新实例； - 要不可变且防篡改（比 Collections 工具类更强）？用
java.util.ImmutableCollections（Java 10+ 的List.of()、Set.copyOf()）或 Guava 的ImmutableList.copyOf()，它们连底层引用都不暴露； - 要线程安全又可变？考虑
CopyOnWriteArrayList或ConcurrentHashMap.newKeySet()，而非给只读集合“强行加锁”； - 对外提供集合字段时，优先返回副本或不可变封装，而非裸露原始集合或其 unmodifiable 包装器（后者仍可能被反射或内部泄漏破坏）。
技术红线总结：三不原则
不捕获、不掩盖、不强转 —— 这是处理此类异常的核心红线：
-
不捕获：不要 try-catch
UnsupportedOperationException来“兜底”，这会掩盖设计缺陷； -
不掩盖：不要用
(ArrayList) list强转只读包装器试图绕过限制（运行时报ClassCastException）； - 不强转：不要假设“反正都是 List”，就往需要可变集合的方法里传 unmodifiableList，应提前校验或重构接口契约。
本质是契约意识：Collections.unmodifiableXXX 是一份清晰的协议——“此集合仅供读取”。尊重它，才能写出稳定、可维护的集合交互逻辑。
