拓扑排序在 C# 中的核心判断依据是什么
拓扑排序能成功执行的前提是：图中无环。一旦存在循环依赖（比如 A → B → A），
TopologicalSort就无法给出合法线性序列，必须提前检测并报错。C# 里不自带拓扑排序 API，得靠
Dictionary<t hashset>></t>建模有向图，再用 Kahn 算法（基于入度）或 DFS 实现；Kahn 更易理解、天然支持环检测，推荐作为首选。
Kahn 算法实现依赖项排序的实操要点
核心是维护一个“当前可执行节点队列”（入度为 0 的节点），每次取出一个，将其后继节点入度减 1，若减到 0 就加入队列。关键细节：
inDegree字典必须覆盖图中所有节点（包括无前驱的和无后继的），漏掉会导致结果缺失 使用
Queue<t></t>而非
Stack<t></t>—— 虽然两者都合法，但栈会改变顺序稳定性，不利于调试和测试复现 最后要检查结果列表长度是否等于节点总数，不等即存在环，此时应抛出
InvalidOperationException("Cycle detected")
若需稳定排序（相同入度时按名称排序），可在入队前对候选节点做 OrderBy，但注意这会增加开销
处理带重复依赖或空依赖项的边界情况
真实项目中常遇到：
ProjectA声明依赖
ProjectB两次、或某个模块声明了空
Dependencies列表。这些不会破坏算法，但容易引发逻辑错误： 建图时对每个依赖调用
dependencies.Add()前，先用
!graph[node].Contains(dependent)去重，避免冗余边影响入度统计 空依赖项要显式加入图节点（哪怕没出边），否则该节点不会出现在
inDegree中，导致最终结果遗漏 若输入是
IEnumerable形式，务必用
Distinct()预处理，防止相同边多次注册
性能与 .NET 版本兼容性提醒
纯字典 + 队列的 Kahn 实现，在 .NET 5+ 上性能足够应对千级节点；但若节点类型是引用类型且未重写
GetHashCode/
Equals，
Dictionary<t ...></t>查找会退化。常见踩坑点： 用
string或
int作节点 ID 最安全；若用自定义类，必须确保
GetHashCode稳定且与
Equals语义一致 .NET Standard 2.0 可用，但避免用
System.Linq.Enumerable.ToHashSet()（需引入
System.Collections.Generic扩展包） 不要在循环中反复新建
HashSet<t></t>存后继节点——复用对象池或预先分配容量更稳妥，尤其当平均出度 > 10 时
实际项目里最麻烦的往往不是算法本身，而是依赖数据来源混乱：JSON 配置字段名不统一、构建脚本生成边时漏了转义、CI 环境下大小写敏感导致节点名不匹配。建议在建图前加一层校验，比如打印所有唯一节点名并人工 spot-check。
