变量被意外修改：分析将集合变量直接暴露给外部接口导致的内部状态破坏

来看一个很常见的场景：你辛辛苦苦设计了一个类，里面维护着一个集合变量——比如待处理订单列表、系统配置项、用户权限集——然后通过一个 getter 直接返回了它的引用。表面上一切正常，直到某个同事（或者未来的你自己）在外部代码里顺手往这个列表里加了一项，而你的类对此毫不知情。

问题不在于“用了集合”，而在于“交出了控制权”。外部代码拿到的是同一份内存对象的钥匙，可以随时开门进去翻东西、放东西，而你的类对此压根儿不知情。

为什么返回原始集合引用等于放弃封装

Ja va、C#、Python 这些主流语言中，集合类型几乎都是引用类型。一旦通过 public 成员变量或者不加防护的 getter 暴露出去，调用方拿到的不是副本，而是一把直接操作内部数据的“钥匙”。

Ja va 示例

public class OrderService {
    private List pendingOrders = new ArrayList<>();
    public List getPendingOrders() { return pendingOrders; } // 危险！
}

外部代码只需一行 service.getPendingOrders().add(new Order())，就能绕过你所有的业务校验逻辑，往 pendingOrders 里塞东西。

Python 示例

class Config:
    def __init__(self):
        self.features = ['login', 'payment']
    def get_features(self):
        return self.features # 返回原列表引用

调用方执行 cfg.get_features().append('analytics')，内部状态就被污染了。

常见但危险的暴露方式

这些写法看起来方便，实际上分分钟打破封装边界：

• public 字段直接声明集合（如 public List tags;）
• getter 方法直接返回私有集合字段（没有做防御性拷贝）
• 构造函数接收到集合参数后，没做深拷贝就直接赋值给成员变量
• Builder 模式中，集合字段被 builder 外部修改后才传入

安全返回集合的 3 套实用办法

核心逻辑就一个：对外提供只读视图或者独立副本，切断外部对内部数据结构的直接操作路径。

Ja va：不可变包装或只读视图

• 返回 Collections.unmodifiableList(pendingOrders)
• Ja va 9+ 直接用 List.copyOf(pendingOrders)（返回不可变副本）
• 如果读多写少，可以考虑 CopyOnWriteArrayList

C#：AsReadOnly() 或 LINQ ToList()

• public IReadOnlyList PendingOrders => _pendingOrders.AsReadOnly();
• 或者 return _pendingOrders.ToList();（返回新列表）

Python：显式复制或封装

• getter 中返回 self._features.copy() 或 tuple(self._features)
• 用 @property 配合 typing.Sequence 类型提示，暗示只读语义

额外防线：从设计源头规避风险

比“亡羊补牢”更重要的是从接口层面重构设计：

• 尽量避免提供“获取整个集合”的方法，转而提供语义化查询，比如 getPendingOrderCount()、findOrderById(id)
• 如果确实需要支持外部增删，那就定义明确的委托方法——addPendingOrder(Order o)、removePendingOrder(id)——在方法内部统一嵌入校验和事件通知
• 在模块导出层面控制可见性（Ja va 的 module-info.ja va、C# 的 internal 修饰符），从根源上阻止跨模块直接访问内部集合

一句话总结：别再随手把集合的“钥匙”递出去了。