Power Collections 实战：用 MultiDictionary 和 Set 优化 .NET 集合操作

简介Power Collections 是一套面向 .NET/C# 开发者的通用集合类库最初由 Wintellect 团队开发并长期维护旨在弥补标准集合框架在数据结构与算法上的不足适合需要更丰富容器类型、希望提升代码复用与开发效率的中高级开发者参考使用。资源包共 59 个文件以 49 个 cs 源码文件为核心辅以 csproj 与 sln 工程文件、dll 二进制程序集、chm 帮助文档及 xml 注释文件另含 config 配置与若干说明文本整体约 1.69MB结构上区分源码、单元测试、文档与二进制目录便于按需查阅与二次开发。目前已有 172 人学习下载。通过该资源读者可获得完整的集合类库源码实现结合单元测试理解各类容器的设计思路与边界处理并借助帮助文档快速掌握 API 用法为日常开发或类库学习提供可直接参考的工程范例。1. Power Collections从一次集合操作翻车说起某次做数据清洗需要把两个大字典按 key 合并值取并集。我随手写了双层循环十万条数据跑了四十多秒。同事看了一眼说用Power Collections里的MultiDictionary试试。改完一秒出头。那一刻我才意识到集合库选对了代码量和运行时间能同时砍掉一个数量级。Power Collections 是一套面向 .NET 的泛型集合扩展库在 BCL 原生ListT、DictionaryK,V之外补齐了有序字典、多重字典、双向链表、集合视图、区间查询这些常用但原生缺失的结构。它解决的核心问题是当你需要「一键多值」「按序索引」「集合运算」时不必自己手写红黑树或哈希桶。适合谁适合每天和 C# 集合打交道、又不想重复造轮子的后端和数据处理开发者。下面按「是什么 → 怎么用 → 坑在哪」推一遍。2. Power Collections 的核心结构与选型逻辑2.1 它到底补了 BCL 哪些缺口原生DictionaryK,V一个 key 只能对应一个 value。要做「一个作者对应多本书」常见做法是Dictionarystring, ListBook每次插入都得判断 key 是否存在、列表是否初始化。Power Collections 的MultiDictionaryTKey, TValue直接把这个模式内置了Add方法自动处理重复 key[key]返回的是一个集合视图而不是单个值。另一个典型缺口是有序字典。BCL 没有内置的平衡树字典很多人用SortedDictionaryK,V但它的 API 相对朴素。Power Collections 的OrderedDictionaryTKey, TValue和OrderedMultiDictionaryTKey, TValue提供了按 key 排序的遍历、范围查询和前驱后继查找底层是红黑树实现插入和查询都是 O(log n)。还有BagT和SetT。SetT做并集、交集、差集、子集判断比手写HashSetT加循环清晰得多。BagT允许重复元素并统计出现次数适合词频统计这类场景。2.2 选型对照什么场景用哪个结构需求BCL 原生方案Power Collections 方案复杂度对比一键多值DictionaryK, ListV手动维护MultiDictionaryK,V代码量减少约 60%按 key 有序遍历SortedDictionaryK,VOrderedDictionaryK,V查询同为 O(log n)API 更丰富集合运算HashSetT 手写循环SetT内置运算符并集/交集一行完成统计重复元素DictionaryT, int手动计数BagT插入即计数双向遍历LinkedListTDequeT/ 双向链表原生 LinkedList 节点操作繁琐选型原则很简单先看 BCL 有没有直接对应没有再看 Power Collections 有没有如果有优先用库里的因为它的边界处理空集合、重复 key、并发修改已经经过测试。我一般会先画一张「操作类型 vs 数据结构」的表把增删改查的频次标出来再决定用哪个。2.3 最小可跑示例MultiDictionary 合并两个数据源下面这段代码模拟两个数据源按 key 合并值取并集。先安装 NuGet 包包名以实际发布为准常见做法是通过 NuGet 管理器搜索安装然后using System; using System.Collections.Generic; using Wintellect.PowerCollections; class Program { static void Main() { // 模拟数据源 A作者 - 书名列表 var sourceA new Dictionarystring, Liststring { { 张三, new Liststring { 算法入门, 数据结构 } }, { 李四, new Liststring { 网络基础 } } }; // 模拟数据源 B作者 - 书名列表 var sourceB new Dictionarystring, Liststring { { 张三, new Liststring { 操作系统 } }, { 王五, new Liststring { 编译原理, 数据库 } } }; // 用 MultiDictionary 做合并 var merged new MultiDictionarystring, string(true); // true 表示允许重复值 foreach (var kv in sourceA) foreach (var book in kv.Value) merged.Add(kv.Key, book); foreach (var kv in sourceB) foreach (var book in kv.Value) merged.Add(kv.Key, book); // 输出合并结果 foreach (var key in merged.Keys) { Console.WriteLine(${key}: {string.Join(, , merged[key])}); } } }逻辑说明MultiDictionary的构造函数参数true表示允许同一个 key 下存在重复值如果传false重复值会被自动去重。merged[key]返回的是一个ICollectionstring视图直接遍历即可。参数说明第一个参数是allowDuplicateValues默认false第二个可选参数是初始容量数据量大时预设容量能减少扩容开销。这段代码在十万条数据量级下合并耗时通常在 200 毫秒以内比双层循环快两个数量级。关键差异在于MultiDictionary内部用哈希表定位 key值列表用数组存储插入是均摊 O(1)。3. 把 Power Collections 用进真实管道的四个步骤3.1 第一步确认目标框架和包来源Power Collections 最初面向 .NET Framework后来有社区移植版本支持 .NET Standard 和 .NET Core。第一步是确认你的项目目标框架。在.csproj里看TargetFramework标签如果是net6.0、net8.0这类需要找支持 .NET Standard 2.0 的包版本。常见做法是在 NuGet 包管理器里搜索包名看最新稳定版的依赖框架列表。如果找不到官方包也可以直接把源码文件拖进项目。Power Collections 的核心文件不多通常包括MultiDictionary.cs、OrderedDictionary.cs、Set.cs、Bag.cs、Deque.cs以及几个辅助类。拖源码的好处是可以直接改坏处是后续升级要手动合并。3.2 第二步用 Set 做集合运算替代手写循环假设有两个用户 ID 列表要找出同时在两个列表里的用户交集以及只在第一个列表里的用户差集。手写循环需要两层嵌套或哈希标记用SetT一行搞定using Wintellect.PowerCollections; var setA new Setint { 1, 2, 3, 4, 5 }; var setB new Setint { 4, 5, 6, 7, 8 }; // 交集 var intersection setA.Intersection(setB); // {4, 5} // 差集在 A 不在 B var difference setA.Difference(setB); // {1, 2, 3} // 并集 var union setA.Union(setB); // {1,2,3,4,5,6,7,8} // 判断子集 bool isSubset new Setint { 1, 2 }.IsSubsetOf(setA); // true逻辑说明Intersection、Difference、Union都返回新的SetT实例不修改原集合。参数方面没有额外配置但要注意SetT内部用哈希表元素类型必须正确实现GetHashCode和Equals。如果元素是自定义类记得重写这两个方法否则集合运算结果会不符合预期。3.3 第三步用 OrderedDictionary 做范围查询有序字典的价值在范围查询。比如有一个按时间戳排序的事件字典要找出某个时间段内的所有事件。原生SortedDictionary需要手动遍历OrderedDictionary提供了RangeFrom、RangeTo、Range方法var events new OrderedDictionaryDateTime, string(); events.Add(new DateTime(2024, 1, 1), 事件A); events.Add(new DateTime(2024, 2, 1), 事件B); events.Add(new DateTime(2024, 3, 1), 事件C); events.Add(new DateTime(2024, 4, 1), 事件D); // 查询 2 月到 3 月之间的事件 var range events.Range( new DateTime(2024, 2, 1), true, new DateTime(2024, 3, 31), true ); foreach (var kv in range) Console.WriteLine(${kv.Key:yyyy-MM-dd}: {kv.Value});逻辑说明Range方法四个参数分别是起始 key、是否包含起始、结束 key、是否包含结束。底层红黑树保证范围查询是 O(log n k)k 是结果数量。参数说明如果起始或结束传null表示不限边界。注意DateTime作为 key 时精度到毫秒如果数据源时间戳精度不同先统一截断。3.4 第四步用 Bag 做词频统计BagT是带计数的集合插入重复元素时自动累加计数。做词频统计比Dictionarystring, int手动判断更简洁var bag new Bagstring(); var words new[] { apple, banana, apple, cherry, banana, apple }; foreach (var w in words) bag.Add(w); foreach (var item in bag) Console.WriteLine(${item.Key}: {item.Value} 次); // 输出apple: 3 次banana: 2 次cherry: 1 次逻辑说明BagT的Add方法在元素已存在时只增加计数不新增条目。遍历时item.Key是元素item.Value是出现次数。参数方面没有特殊配置但要注意BagT不保证遍历顺序如果需要按次数排序先转成列表再排。4. 避坑Power Collections 的五个血泪教训4.1 坑一MultiDictionary 的默认去重行为现象往MultiDictionary里插入重复值结果只保留了一个。原因构造函数默认allowDuplicateValues是false重复值被静默丢弃。解决创建时显式传true或者在插入前用ContainsValue判断。我一般会在变量名里加AllowDup后缀提醒自己。4.2 坑二OrderedDictionary 的 key 必须可比较现象自定义类作为 key 时OrderedDictionary插入报InvalidOperationException。原因红黑树需要比较 key 的大小自定义类没有实现IComparableT。解决让类实现IComparableT或者在构造OrderedDictionary时传入IComparerT实例。后者更灵活不用改类定义。4.3 坑三Set 运算返回新实例不是原地修改现象调了setA.Union(setB)之后setA没变以为方法失效。原因Union、Intersection、Difference都返回新SetT原集合不动。解决如果需要原地修改用setA.UnionWith(setB)这类方法或者把返回值赋回原变量。这个设计其实更安全避免意外修改共享集合。4.4 坑四Bag 的计数在删除时不会自动归零现象从Bag里删除一个元素计数减一但计数为零的条目仍然留在集合里遍历时还能看到。原因Bag的Remove只减计数不删条目。解决用RemoveAll彻底删除或者在遍历时跳过Value 0的条目。如果做词频统计后要输出记得过滤零计数。4.5 坑五并发场景下所有结构都不是线程安全的现象多线程同时往MultiDictionary插入数据偶尔丢数据或抛异常。原因Power Collections 的所有结构都没有内置锁和 BCL 的Dictionary一样。解决要么在外部加lock要么用ConcurrentDictionary替代。如果读多写少可以考虑ReaderWriterLockSlim但复杂度会上升。我的习惯是单线程用 Power Collections多线程先考虑 BCL 的并发集合。5. 进阶用 View 做零拷贝过滤与一个验证习惯Power Collections 里有一个容易被忽略的能力集合视图。MultiDictionary的[key]返回的就是一个视图对视图的修改会反映到原字典。类似地OrderedDictionary的Range返回的也是视图不是拷贝。这意味着你可以基于一个大集合派生出多个过滤视图而不复制数据。看一个例子有一个大的OrderedDictionaryint, string要分别处理偶数和奇数 key 的条目。常见做法是遍历两遍或者拷贝到两个列表。用视图可以这样做var bigDict new OrderedDictionaryint, string(); for (int i 0; i 100; i) bigDict.Add(i, $值{i}); // 派生偶数视图从 0 开始步长 2 var evenView bigDict.Range(0, true, 98, true) .Where(kv kv.Key % 2 0); // 派生奇数视图 var oddView bigDict.Range(1, true, 99, true) .Where(kv kv.Key % 2 ! 0); // 两个视图共享底层数据不产生拷贝 foreach (var kv in evenView) Console.WriteLine($偶数: {kv.Key});逻辑说明Range返回的是原字典的一个区间视图Where是 LINQ 延迟执行整个链条在遍历时才真正求值。参数方面Range的边界参数和前面一样Where的谓词按需写。注意视图是只读的如果要对视图元素做修改需要回到原字典操作。验证方法我习惯在写完集合操作后用一个小数据集跑一遍把结果打印出来和手写循环的结果对比。具体做法是写一个Verify方法输入两个集合分别用 Power Collections 和手写循环计算断言结果一致。这个习惯帮我抓过好几次边界错误比如空集合、单元素集合、重复元素这些情况。static void VerifySetOperation() { var a new Setint { 1, 2, 3 }; var b new Setint { 3, 4, 5 }; // Power Collections 结果 var libResult a.Intersection(b).ToList(); // 手写循环结果 var manualResult new Listint(); foreach (var x in a) if (b.Contains(x)) manualResult.Add(x); // 断言一致 libResult.Sort(); manualResult.Sort(); if (!libResult.SequenceEqual(manualResult)) throw new Exception(集合运算结果不一致); }这个验证方法不依赖测试框架直接跑就行。参数方面没有特殊配置但要注意SetT的遍历顺序不保证所以比较前先排序。我一般会在项目初期把这类验证方法集中放在一个文件里每次升级库版本或改集合逻辑时跑一遍。最后一个习惯不要因为 Power Collections 提供了某个结构就硬用它。BCL 的ListT和DictionaryK,V在大多数场景下已经够用Power Collections 的价值在特定缺口。先问自己「原生结构能不能做」能就不引入新依赖。这个判断顺序帮我避免了不少过度设计。希望帮到你。本文还有配套的精品资源点击获取