简介Power Collections 是一个由 Wintellect 公司出品的 C# 集合类增强库面向需要高级数据结构的 .NET 开发者。它突破了标准集合库在特定场景下的局限提供更丰富的集合操作与算法支持适合用于算法研究、底层框架扩展以及复杂业务数据组织。压缩包仅 1.69MB共 59 个文件其中 49 个 C# 源码文件完整呈现各集合类的实现思路解决方案与工程文件保障了项目结构的完整性帮助文档与注释便于使用者快速查阅接口而编译好的程序集可直接集成到项目同时附带的单元测试工程让学习者能够边看实现边验证功能。已有 166 名开发者学习或下载既适合中高级 C# 程序员深入理解集合类内部原理也适合希望快速引入成熟数据结构的项目团队在遵守 Eclipse 许可协议的前提下免费使用。 做.NET开发这些年有一件事我一直觉得挺别扭数据结构教材上写得明明白白的东西——栈、队列、双端队列、优先队列、有序字典、多重集合——到了C#里标准库翻来覆去就是List、Dictionary、Queue、Stack这老四样。想用一个双端队列要么自己用链表包一层要么去StackOverflow抄一段想用优先队列更是要手写二叉堆。今天聊的这个Power Collections就是为了补齐这些基础数据结构而生的开源集合类库作者是写过《CLR via C#》的Jeffrey Richter光这个名头就值得看一眼。Power CollectionsNuGet上的包名是Wintellect.PowerCollections提供了一整套比标准库更“高级”的集合类型双端队列DequeT、按键而非插入顺序排列的OrderedDictionaryTKey, TValue、二叉堆实现的PriorityQueueT、允许重复元素的BagT和OrderedBagT、一个键映射多个值的MultiDictionaryTKey, TValue还有静态算法类Algorithms里面装着洗牌、排列组合、拓扑排序等一堆实用操作。如果你写业务系统时遇到过“临时需要某个数据结构但不想引一个重型框架”的尴尬或者刷算法题时发现有几种数据结构C#没有原生版本这篇博文应该能帮你省下不少时间。1. Power Collections是什么为什么值得保留1.1 项目背景和定位Power Collections最初是Wintellect公司开源的一套.NET集合类库目的只有一个把.NET Framework早期版本缺失的经典数据结构补上。你想想SortedDictionary在.NET 2.0时代就有了但Deque、PriorityQueue、Bag这些数据类型至今没有进入标准库.NET 6才开始有PriorityQueue但使用方式比这个库的API少一些。所以这十几年里很多.NET开发者遇到“队列的增强版”“字典的有序版”之类需求时第一反应就是装这个包。定位上它和System.Collections、System.Collections.Generic是平级的关系不替代原生集合而是补位。它的设计风格很“老派但扎实”所有公共集合类型都有完整的接口定义IDequeT、IOrderedDictionaryTKey, TValue迭代器实现规范还带一大堆扩展算法。这种“教科书式的严谨”在如今这个“什么都要自己造一套”的时代反而显得珍贵。1.2 与原生集合的对比很多人问标准库里有List、Dictionary、HashSet我为啥还要多引一个依赖拿几个典型场景对比一下你就明白了ListT的Insert(0, item)时间复杂度是O(n)因为底层是数组头部插入要搬移所有元素DequeT的两端插入都是O(1)底层是循环数组。DictionaryTKey, TValue是无序的想按Key遍历排序就得每次OrderByOrderedDictionaryTKey, TValue本身按Key维护红黑树遍历即有序查找和插入都是O(log n)。QueueT只能先进先出想按优先级取元素没辙PriorityQueueT直接给你一个二叉堆Dequeue()永远取出当前优先级最高的元素。DictionaryTKey, TValue一个Key只能对应一个ValueMultiDictionaryTKey, TValue一个Key能挂一串Value免去了Dictionarystring, Liststring那种手写嵌套的麻烦。提示Power Collections的这些类型并不是性能银弹它强在“正好有这个结构不用自己造”。在数据量不大时List加LINQ也能凑合但数据量上来之后选对数据结构带来的收益是指数级的。2. 核心数据结构逐个拆解2.1 Deque双端队列两端都能快速进出的“双开门队列”DequeT是我用得最多的类型。它解决了QueueT只能一头进另一头出、StackT只能一端操作的痛点。在C#里标准库没有原生双端队列很多人在滑动窗口、工作队列、撤销重做这样的场景里只能用链表模拟麻烦不说稍不注意就会写出O(n²)的代码。using Wintellect.PowerCollections; var deque new Dequeint(); deque.AddToBack(1); // 尾部插入 [1] deque.AddToFront(0); // 头部插入 [0, 1] deque.AddToBack(2); // 尾部插入 [0, 1, 2] int head deque.RemoveFromFront(); // 取出并移除头部head 0 int tail deque.RemoveFromBack(); // 取出并移除尾部tail 2 int first deque[0]; // 也支持索引器随机访问 int last deque[deque.Count - 1];底层实现是循环数组circular buffer。什么概念想象一个固定长度的圆圈头部指针和尾部指针在圈上转头部往前挪一格、尾部往后挪一格。这样两端插入删除都不需要搬移元素空间利用率也高还能随机访问。相比之下ListT头部插入要搬移后面所有元素这就是O(1)和O(n)的差距。适用场景滑动窗口类的算法题比如LeetCode 239。实时数据流处理既要保留最近N条数据又要偶尔从头部淘汰旧的。浏览器前进后退、编辑器撤销重做这类“双向操作”的状态栈。2.2 OrderedDictionary有序字典按Key排序而不是按插入顺序说一个特别容易踩的坑Power Collections里的OrderedDictionaryTKey, TValue和.NET Framework自带的System.Collections.Specialized.OrderedDictionary名字一模一样功能完全相反。后者是“按插入顺序排序”前者是“按Key的排序规则排序”。用之前一定要确认using的是哪个命名空间。using Wintellect.PowerCollections; var dict new OrderedDictionarystring, int(); dict[banana] 1; dict[apple] 2; dict[cherry] 3; foreach (var key in dict.Keys) { Console.WriteLine(${key}: {dict[key]}); } // 输出 // apple: 2 // banana: 1 // cherry: 3底层是红黑树。红黑树这个结构工程上非常经典插入、删除、查找都是O(log n)并且中序遍历就能得到有序序列。相比“用Dictionary存数据、需要时再OrderBy”它在“持续插入 频繁按序读取”的场景下优势明显因为不需要每次读取时重新排序。适用场景排行榜、价格表这类始终需要按Key有序展示的数据。区间查找、范围查询配合Range(from, to)方法能直接取出Key在某范围内的所有键值对。需要“有序字典 随机访问”的业务场景比如按用户名排序的用户在线列表。2.3 PriorityQueue优先级队列任务调度的好帮手.NET 6终于官方加了PriorityQueue但如果你还在维护老项目或者需要更丰富的比较器、更稳定的堆排序实现Power Collections的优先级队列依然值得了解。API非常简单Enqueue进堆Dequeue出堆出的永远是“优先级最高”的那个。var pq new PriorityQueuestring(); pq.Enqueue(普通任务); pq.Enqueue(紧急任务); pq.Enqueue(低优先级任务); // 默认是最小堆按字符串默认比较规则取“最小”的 // 如果你想让“紧急任务”这样的字符串先出队需要传入自定义比较器 while (pq.Count 0) { Console.WriteLine(pq.Dequeue()); }这里有个关键点默认构造的PriorityQueueT用的是默认比较器对于引用类型或数字类型取的是“最小的先出”。如果你想要的是“最大的先出”或者按对象的某个属性排序必须传入自定义的IComparerT。常见的做法是实现一个反转比较器public class ReverseComparerT : IComparerT { private readonly IComparerT _inner; public ReverseComparer(IComparerT inner) _inner inner; public int Compare(T? x, T? y) _inner.Compare(y, x); } var maxHeap new PriorityQueueint(new ReverseComparerint(Comparerint.Default)); maxHeap.Enqueue(3); maxHeap.Enqueue(1); maxHeap.Enqueue(2); Console.WriteLine(maxHeap.Dequeue()); // 3最大优先适用场景任务调度按紧急程度、优先级处理队列里的任务。Dijkstra最短路径算法里“取当前距离最小的顶点”。多路归并排序、Top K问题等堆几乎是标准答案。2.4 Bag、MultiDictionary等冷门但好用的类型BagT又称多重集合multiset允许同一个元素出现多次而且可以稳定记录每个元素出现了多少次。OrderedBagT则在保持有序的同时允许重复元素。这在统计词频、库存计数等场景非常顺手。var bag new Bagstring(); bag.Add(apple); bag.Add(apple); bag.Add(banana); int appleCount bag.GetNumberOfCopies(apple); // 2 bag.Remove(apple); // 移除一个apple bag.RemoveOneCopiesOf(banana); // 移除一个或所有? 这个方法要看版本MultiDictionaryTKey, TValue解决的是“一个Key对应多个Value”的问题。平时我们写Dictionarystring, Liststring要自己处理“Key不存在就创建List”的逻辑用MultiDictionary一步到位var multi new MultiDictionarystring, string(allowDuplicateValues: true); multi.Add(fruit, apple); multi.Add(fruit, banana); multi.Add(fruit, banana); // allowDuplicateValuestrue 时允许重复值 foreach (var pair in multi) { Console.WriteLine(${pair.Key}: {pair.Value}); } // fruit: apple // fruit: banana // fruit: banana // 删除 multi.Remove(fruit, banana); // 只移除这一个banana bool exists multi.ContainsKey(fruit); // 真MultiDictionary构造函数里那个bool参数表示同一个Key下面是否允许重复的Value这个细节容易忽略用之前一定要确认业务需求。它的Count属性统计的是“键值对总数”不是Key的个数这也和字典的语义不一样。OrderedSetT、OrderedMultiDictionaryTKey, TValue等类型都是同一个套路加上“有序”就换红黑树不加则用哈希表。理解了红黑树和哈希表的本质这些API的取舍就一目了然了。3. 三个经典场景的实操演练3.1 滑动窗口最大值用Deque把复杂度压到O(n)LeetCode 239是道经典题给定数组和窗口大小k求每个窗口的最大值。最朴素的两层循环是O(n·k)数据一大就超时。用Deque维护窗口内的候选最大值索引可以达到O(n)public int[] MaxSlidingWindow(int[] nums, int k) { if (nums.Length 0) return new int[0]; var deque new Dequeint(); // 存储索引 var result new int[nums.Length - k 1]; for (int i 0; i nums.Length; i) { // 移除队尾所有比当前元素小的索引 while (deque.Count 0 nums[deque.Last] nums[i]) deque.RemoveFromBack(); deque.AddToBack(i); // 移除队头已经滑出窗口的索引 if (deque.First i - k) deque.RemoveFromFront(); // 窗口形成后记录最大值 if (i k - 1) result[i - k 1] nums[deque.First]; } return result; }这个解法能跑通核心就是Deque两头都能高效增删队尾淘汰“肯定不是最大值”的候选队头弹出“已经过期”的元素。换成List模拟的话RemoveAt(0)一次就是O(n)整体又变回O(n·k)。很多算法优化的本质就是数据结构选对Deque在这里几乎是为题目量身定做的。3.2 优先级任务调度用PriorityQueue替代手工排序实际业务里任务队列最常见的需求不是“先来先服务”而是“急事优先”。比如工单系统一个“系统崩了”的工单必须排在“功能咨询”前面。用List 每次Sort或者OrderBy数据量小没问题但任务多、并发高的时候就会成为性能瓶颈。用PriorityQueue就清爽得多public class Ticket { public string Id { get; set; } public int Priority { get; set; } // 数值越小越紧急 public string Desc { get; set; } } public class TicketComparer : IComparerTicket { public int Compare(Ticket? x, Ticket? y) { return y.Priority.CompareTo(x.Priority); // 注意反转 } } var queue new PriorityQueueTicket(new TicketComparer()); queue.Enqueue(new Ticket { Id T001, Priority 5, Desc 咨询 }); queue.Enqueue(new Ticket { Id T002, Priority 1, Desc 系统崩溃 }); var next queue.Dequeue(); // T002系统崩溃优先这里最大的坑就是比较器方向。PriorityQueue的Dequeue总是取出“在比较器视角下最小”的元素。如果你把Priority设为“数值越大越紧急”那么Compare里要用y.Priority.CompareTo(x.Priority)或者直接传入一个反转比较器。我第一次用的时候就是没反转结果所有“最紧急”的都排在最后面被测试狠狠教育了一顿。3.3 动态排名表OrderedDictionary的典型应用举个例子直播平台的礼物榜每分钟都有新的礼物数据进来需要实时展示“当前排行”。如果每次都用Dictionary存完再OrderBy数据一多就很吃力。用OrderedDictionary按分数排序插入时自动定位天然是排好序的var ranking new OrderedDictionarystring, long(); // 模拟用户收入 ranking[userA] 100; ranking[userB] 50; ranking[userA] 200; // 累加 foreach (var pair in ranking) { Console.WriteLine(${pair.Key}: {pair.Value}); }不过要注意OrderedDictionary是按Key排序不是按Value排序。如果你想让“分数高的人排前面”要么把“分数”设计成Key但要保证唯一要么用OrderedMultiDictionary按分数分组或者直接用List 每次维护。这个细节反映了这类字典的适用边界它适合“按键有序”不适合“按值有序”的场景。4. 常见问题与避坑指南4.1 命名空间冲突两个OrderedDictionary要分清这个在前面已经提过但值得再说一遍。System.Collections.Specialized.OrderedDictionary是.NET Framework自带的按插入顺序排列Key和Value的类型都是objectWintellect.PowerCollections.OrderedDictionaryTKey, TValue是泛型版本按Key排序。如果不小心using了两个命名空间编译器会直接报“不明确”的错排查起来很抓狂。我的习惯是用这个库的时候加别名。using Power Wintellect.PowerCollections; var dict new Power.OrderedDictionarystring, int();这样代码里看到Power.OrderedDictionary一眼就知道是哪个不用来回猜。4.2 版本与NuGet引用在NuGet上搜索“PowerCollections”会看到两个包一个叫PowerCollections另一个叫Wintellect.PowerCollections。老项目里可能有人直接引用了前者但那个基本是远古版本没有维护了。推荐用Wintellect.PowerCollections最新版本支持.NET Framework 4.0和.NET Standard 2.0也就是说.NET Core、.NET 5/6/7/8都能用兼容性有保障。安装命令dotnet add package Wintellect.PowerCollections有些跑在.NET Framework老版本系统上的项目可能装了旧版比如1.0.0注意看依赖框架和目标框架是否匹配。4.3 线程安全不是银弹Power Collections的集合类型大部分不是线程安全的甚至没有像ConcurrentDictionary那样的并发版本。多线程环境下的选择加锁用lock包裹每次读写简单但吞吐量有限。用并发集合替代.NET标准库的ConcurrentQueueT、ConcurrentDictionaryTKey, TValue在某些场景下是更好的选择。使用不可变集合System.Collections.Immutable里的ImmutableQueueT、ImmutableSortedDictionaryTKey, TValue等。我的经验是如果只是单线程内部使用比如请求处理中临时维护数据结构Power Collections完全没问题如果要做跨线程的共享队列老老实实用ConcurrentQueue或者自己加锁别指望这个库替你兜底。4.4 自定义比较器一个比较器引发的血案OrderedDictionary、OrderedSet、PriorityQueue、Bag等类型很多构造函数都接受IComparerT参数。如果你不传默认使用ComparerT.Default也就是类型的默认比较规则。这在自定义类型上特别容易出问题——比如你定义了一个Person类没实现IComparable构造OrderedSetPerson时就会在运行时抛异常。// ❌ 错误示范Person没有实现IComparable运行时会崩 var set new OrderedSetPerson(); // ✅ 正确示范传入自定义比较器 var set2 new OrderedSetPerson((p1, p2) p1.Age.CompareTo(p2.Age));另外凡是涉及字符串大小写的场景记得考虑StringComparer.OrdinalIgnoreCase。默认的比较器是区分大小写的apple和Apple会被当成两个不同的键这在业务上常常不是你想要的结果。4.5 和LINQ的配合Power Collections的集合类型大都实现了IEnumerableT所以可以正常用LINQ。但有一个性能陷阱在OrderedDictionary上使用Where、OrderBy这类操作时会丢失底层的排序结构语义因为它们返回的是新的迭代序列。如果你只是为了过滤可以用Range、RangeFrom这类原生的范围方法底层树结构能够利用排序信息做高效的部分遍历。这算是一个“用对API比事后优化更强”的典型案例。5. 这个库还能怎么扩展如果你觉得Power Collections只是提供了一堆数据结构那就低估它了。它还带了一个Algorithms静态类包含很多实用算法。我自己用过几个配合集合类型非常好用Algorithms.RandomShuffle(list)Fisher-Yates洗牌在做抽奖、随机出题功能时直接可用。Algorithms.Permutations(list)生成所有排列测试组合场景时方便。Algorithms.CartesianProduct(c1, c2)笛卡尔积在做商品规格矩阵颜色×尺寸时能省不少代码。Algorithms.TopologicalSort(dict)拓扑排序处理任务依赖关系时很管用。var list new Listint { 1, 2, 3, 4, 5 }; Algorithms.RandomShuffle(list); // 之后list的顺序是随机的 var colors new Liststring { 红, 蓝 }; var sizes new Liststring { S, M, L }; var product Algorithms.CartesianProduct(colors, sizes); // 输出红S, 红M, 红L, 蓝S, 蓝M, 蓝L这些算法都是扩展方法或者静态方法不需要你自己再写递归、回溯直接用就行。坦白说它们的API稍显“老古董”但胜在实现稳、坑少比网上东拼西凑的代码靠谱。写在最后说了这么多提炼一句核心体会选集合类型这件事本质是在选“底层数据结构”。数组适合随机访问、链表适合频繁增删、哈希表适合精确查找、树结构适合有序遍历、堆适合取最值。标准库给了你最常用的几种剩下的它没给Power Collections正好帮你补上。我在实际项目中用它的频率不算特别高但每次用到都是“刚需”滑动窗口算法用Deque、任务排序用PriorityQueue、动态排行榜用OrderedDictionary。这个库的唯一缺点可能就是成熟得太早API风格还停留在.NET 2.0年代用起来没有标准库那么“丝滑”但数据结构这种东西稳定可靠比新潮重要多了。如果哪天你在项目里发现“标准库不够用”不妨先试试这个老牌库它大概率不会让你失望。本文还有配套的精品资源点击获取