Java的Collection接口与Guava的ImmutableCollection并非替代关系，而是分别面向可变性与不可变性的不同设计目标：前者定义add/remove等可变操作契约，后者通过抛出UnsupportedOperationException强制不可变，并提供线程安全、无null、内存紧凑等优势。
Java标准库的Collection接口和Guava的ImmutableCollection不是替代关系，而是面向不同设计目标的抽象：前者强调可变性与通用契约，后者专注不可变性与安全语义。
Collection 接口：为可变操作而设计的契约
Collection是Java集合框架的顶层接口，定义了add、remove、clear等写操作方法。它的核心理念是“可变容器”，所有实现类（如ArrayList、HashSet）默认支持动态增删改。这种设计便于日常业务开发，但也带来隐含风险：
- 调用方无法从接口本身判断集合是否会被修改
- 作为参数传入方法时，接收方可能意外改变原始数据
- 多线程环境下需额外同步，否则易出现竞态条件
- 防御性拷贝需手动编写，容易遗漏或出错
ImmutableCollection：以“不可变”为第一原则的实现
ImmutableCollection不是接口，而是Guava提供的抽象基类，它不继承Collection的写操作语义，而是通过覆盖全部修改方法并抛出UnsupportedOperationException来强制不可变。它的设计出发点是：一旦创建，内容就固定不变。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 所有构造方式（
of()、copyOf()、Builder.build()）都执行深拷贝或内部固化，与原集合彻底解耦 - 不接受
null值，避免95%场景下因空指针引发的隐蔽错误 - 线程安全天然成立——没有状态变化，无需同步开销
- 内存更紧凑：跳过并发修改检查、扩容机制、哈希桶预留等可变结构的冗余字段
两者在使用逻辑上的关键分野
选择哪一种，取决于你对数据生命周期的预期：
立即学习“Java免费学习笔记（深入）”；
- 需要频繁增删查改 → 用
ArrayList、LinkedHashSet等标准实现 - 初始化后不再变更，且要防止被误改 → 优先用
ImmutableList.copyOf(list) - 作为常量公开字段（如配置项、枚举集合）→ 必须用
ImmutableSet.of("A", "B")，而非Collections.unmodifiableSet(...) - 跨模块/跨包传递集合参数 → 用Immutable可消除“对方会不会偷偷改”的信任成本
为什么不是简单替换？
Guava没让ImmutableCollection实现Collection接口，是有意为之。如果强行实现，就必须提供add()等方法——哪怕只是抛异常，也会误导调用者以为“这是一个Collection”。它选择用独立类型体系表达设计意图：不可变就是不可变，不妥协、不模糊。
