只有有向无环图（DAG）才有拓扑排序，所谓“集合的拓扑排序”实为对顶点集合V按有向边关系进行的排序；需用邻接表或Map构建图并运行Kahn或DFS算法，因邻接表空间高效、支持非连续/字符串顶点名、便于动态更新；Kahn算法中须显式初始化所有顶点入度，用merge或get-default方式安全更新，结果长度小于顶点数即表明存在环。
集合没有拓扑排序——只有有向无环图（DAG）才有拓扑排序。你看到的“集合的拓扑排序”其实是误称，真实场景中，所谓“集合”是指图的顶点集合 V，而排序依据是顶点之间的有向边关系（即依赖、先后、约束），不是集合本身的数学结构。真正要做的，是基于邻接表或 Map 构建的有向图，跑一遍 Kahn 或 DFS 拓扑算法。
为什么必须用邻接表或 Map？直接用数组不行吗
邻接表（如 vector<list>></list> 或 Map<integer list>></integer>）是稀疏图的事实标准：它只存真实存在的边，空间复杂度为 O(V + E)；而邻接矩阵要用 O(V²) 存储，对 10⁴ 个节点、仅百条边的依赖图来说，99.9% 的内存全是浪费的零值。
更关键的是：实际工程中（如 Maven 编译、npm install、CI 任务调度），顶点名常是非连续整数或字符串（如 "api-service"、"v2.3.1"），根本没法用纯数组下标索引。
- 用
Map<string list>></string>可直接映射模块名到依赖列表，无需编号预处理 - 邻接表支持动态增删边（比如热更新依赖），数组则需重建整个结构
- Java/Python 中
Map的 keySet() 天然提供顶点集合视图，但注意：它不保证顺序，不能直接当拓扑结果用
Kahn 算法里入度数组怎么配 Map 一起用
核心矛盾在于：Map 没下标，但入度必须按顶点一一对应。常见错误是试图用 Map<vertex integer></vertex> 存入度，结果遍历时 key 乱序、漏初始化、或查不到新顶点。
- 正确做法：先扫描所有边，用
Set<vertex></vertex>收集全部顶点（包括只有出边、无入边的起点），再为每个顶点在Map<vertex integer></vertex>中显式设初值0 - 别省略“无入边顶点”的入度初始化——它们才是拓扑起点，漏了就进不了队列，导致结果为空
- 更新入度时，必须用
indegree.merge(v, 1, Integer::sum)（Java）或indegree[v] = indegree.get(v, 0) + 1（Python），避免NullPointerException或 KeyError - 队列初始只加
indegree.get(v) == 0的顶点，不是所有keySet()
Map 实现的拓扑排序为何常返回空结果或长度不够
这不是代码写错，而是图含环的真实信号。Kahn 算法天然具备环检测能力：最终结果列表长度 != 顶点总数，就说明有向环存在。
- 典型现象：
result.size() == 3，但vertices.size() == 5→ 剩下 2 个顶点互相依赖（如 A→B 且 B→A）或构成三元环（A→B→C→A） - 调试技巧：在算法退出后，遍历所有顶点，打印
indegree.get(v)，非零值顶点就是环上成员（或被环拖累的下游节点） - Map 键冲突陷阱：若用
String作顶点但未重写equals/hashCode（如用了自定义对象却没规范实现），会导致同一逻辑顶点被算作多个，入度统计失真 - 并发修改异常：遍历
Map.entrySet()同时又调用remove()或put()，会触发ConcurrentModificationException——应改用线程安全容器或先收集待删键再批量操作
真正难的从来不是写完算法，而是确认输入图是否满足 DAG 前提。依赖配置写错一个箭头，整个拓扑就崩；Map 的 key 设计不合理，运行时才暴露缺失顶点。这些不在教科书里，但在上线前的 debug 日志里反复出现。
