在C#中，如果一个类内部使用List来维护状态，却把这个List直接通过属性返回给外部，调用方就能随意添加或删除元素，造成内部状态被意外篡改。要解决这个问题，最简单的办法是返回一个只读集合。ReadOnlyCollection就是为此设计的类型，它提供只读索引、枚举和计数，但不暴露任何修改方法。
本文就从创建方式、接口对比和实际场景三个角度，说明ReadOnlyCollection的基础用法以及需要注意的边界。
一、ReadOnlyCollection是什么？
ReadOnlyCollection位于System.Collections.ObjectModel命名空间，是一个泛型只读集合类。它的构造函数接收一个IList实例，并在内部保存该列表的引用，之后通过索引器、GetEnumerator和Count向外提供只读访问。关键点在于，它并不是把数据复制到新的数组，而是直接包装原始列表，因此包装过程非常轻量，不会产生额外的内存开销。
创建时通常使用new ReadOnlyCollection<T>并传入一个可变列表。下面的代码演示了最基本的创建和读取操作，同时说明只读集合没有Add、Remove等方法，任何试图修改集合结构的调用在编译阶段就会被拦截。
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
class Program
{
static void Main()
{
List<string> names = new List<string> { "Alice", "Bob", "Carol" };
ReadOnlyCollection<string> readOnlyNames = new ReadOnlyCollection<string>(names);
Console.WriteLine(readOnlyNames[0]); // Alice
Console.WriteLine(readOnlyNames.Count); // 3
// readOnlyNames.Add("Dave"); // 编译错误：ReadOnlyCollection没有Add方法
// readOnlyNames.Remove("Alice"); // 编译错误
names.Add("Dave");
Console.WriteLine(readOnlyNames.Count); // 4，只读视图反映了底层变化
}
}
运行这段代码会发现，当底层names列表添加元素后，readOnlyNames的Count也会变化。这说明ReadOnlyCollection只是一个只读窗口，它不会阻止原始列表的修改。如果需要完全不可变的数据快照，应该在包装前复制一份列表，比如使用List的构造函数、ToArray或复制到新的List后再包装。
二、为什么不能直接用IEnumerable或IReadOnlyList？
有人会觉得，返回IEnumerable就可以防止修改，因为调用方只拿到枚举接口。但实际上，IEnumerable并没有真正阻止类型转换。如果方法签名返回IEnumerable，调用方完全可以把对象强制转换回List，然后修改内部数据。下面的代码展示了这种风险：
using System;
using System.Collections.Generic;
class OrderService
{
private List<string> orderIds = new List<string> { "101", "102", "103" };
public IEnumerable<string> GetOrderIds()
{
return orderIds;
}
}
class Program
{
static void Main()
{
OrderService service = new OrderService();
IEnumerable<string> ids = service.GetOrderIds();
// 调用方可以通过强制类型转换拿到原始List
List<string> list = ids as List<string>;
if (list != null)
{
list.Clear(); // 内部集合被清空
}
}
}
IReadOnlyList接口相对更安全一些，因为它只声明了只读成员，但接口本身并不保证实现类不能修改。只要实现类同时实现了IList，调用方仍然可以通过类型判断强制转换。例如，一个方法声明返回IReadOnlyList，但实际返回的是List，调用方仍然能够将其转换回List并修改。这属于接口抽象不足导致的封装漏洞。
ReadOnlyCollection则不同，它是一个具体的包装类，内部只保存IList引用，不会把列表的修改方法暴露出来。虽然底层列表引用仍然可以被反射等非常规手段访问，但在正常的类型安全环境下，调用方没有办法通过编译器认可的转换来获得可变接口。因此，对于需要对外提供集合数据的场景，优先选择ReadOnlyCollection或使用List的AsReadOnly方法，比简单返回IEnumerable或IReadOnlyList更安全。
另外还要区分ReadOnlyCollection与数组副本。数组副本可以隔离修改，但每次返回都需要复制，成本较高。而ReadOnlyCollection包装不会复制，适合高频访问或数据量较大的场景。如果数据量小且希望绝对隔离，直接返回新数组也是一种选择。
三、ReadOnlyCollection的常见使用场景
第一个典型场景是领域模型中的集合属性。比如一个订单类内部维护订单明细列表，但不希望外部任意修改明细项。可以在类内部保存List，对外暴露ReadOnlyCollection属性。这样外部可以遍历明细、按索引读取，却不能添加或删除明细。示例代码如下：
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
public class Order
{
private List<OrderItem> _items = new List<OrderItem>();
public ReadOnlyCollection<OrderItem> Items
{
get { return _items.AsReadOnly(); }
}
public void AddItem(OrderItem item)
{
if (item == null)
throw new ArgumentNullException(nameof(item));
_items.Add(item);
}
public void RemoveItem(string productId)
{
_items.RemoveAll(i => i.ProductId == productId);
}
}
public class OrderItem
{
public string ProductId { get; set; }
public decimal Price { get; set; }
}
在这个例子中，Order类通过公有方法AddItem和RemoveItem控制修改，而Items属性返回的ReadOnlyCollection让外部只能读取。这样既保护了集合结构，又保留了业务层面对集合变动的控制权。
第二个场景是缓存只读快照。某些服务需要把缓存数据提供给多个调用方，而调用方不应该修改缓存本身。可以将缓存保存为List，对外提供List的AsReadOnly方法返回的包装。注意，如果缓存后续会更新，而调用方希望拿到某一时刻的快照，那么仅靠ReadOnlyCollection无法实现，因为底层列表更新后视图也会变。此时需要先复制列表，再包装副本。
第三个场景是数据绑定。在WPF或WinForms中，把集合绑定到控件后，如果控件代码尝试修改集合结构而集合只读，可以避免界面与内部状态不同步。ReadOnlyCollection虽然不是ObservableCollection，不能自动通知界面更新，但如果数据不需要动态通知，它仍然适合作为数据源。
四、使用ReadOnlyCollection的注意事项
首先要明确，ReadOnlyCollection只保证集合本身不可变，不保证集合中元素的内部状态不可变。如果集合元素是引用类型，调用方完全可以修改元素的属性。比如下面的代码中，虽然集合是只读的，但可以通过索引获取元素并修改其Name属性。
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
class Program
{
class Person
{
public string Name { get; set; }
}
static void Main()
{
List<Person> people = new List<Person> { new Person { Name = "Tom" } };
ReadOnlyCollection<Person> readOnlyPeople = people.AsReadOnly();
readOnlyPeople[0].Name = "Jerry"; // 允许，修改的是元素内部状态
Console.WriteLine(people[0].Name); // Jerry
// readOnlyPeople.Add(new Person()); // 编译错误
}
}
如果连元素内部状态也要保护，必须使用不可变类型，例如将属性的set访问器设为private，或者使用record和init-only属性。这是另一个层次的问题，不能只依赖ReadOnlyCollection解决。
其次，ReadOnlyCollection不是线程安全的。多个线程同时读取通常没问题，但如果一个线程遍历只读集合，另一个线程修改底层列表，就可能发生集合已修改的异常。因此，在多线程环境下，应该使用并发集合或者在访问时加锁，并考虑返回真正的快照。
最后，关于IReadOnlyList与ReadOnlyCollection的选择。IReadOnlyList是一个接口，表示只读索引访问，适合作为方法参数类型，因为它允许传入数组、List或ReadOnlyCollection等任意实现。ReadOnlyCollection是一个具体包装类，适合作为返回值类型，因为调用方无法通过正常类型转换修改它。两者可以配合使用：方法参数用IReadOnlyList提高灵活性，返回对外暴露时用ReadOnlyCollection保证安全。
总之，ReadOnlyCollection是保护集合数据的第一道防线，理解它的包装语义和局限，才能在实际项目中合理地设计只读接口。
C# ReadOnlyCollection只读集合数据保护修改时间：2026-09-27 20:10:29