kahn算法实现拓扑排序需显式初始化所有节点入度：输入为[][]int时用切片并按节点范围初始化；输入为map[string][]string时须先收集全部节点再映射或直接用字符串处理；漏初始化会导致孤立节点丢失或panic，检测环应基于完整节点集而非图中键数。
用 topologicalSort 函数做任务依赖调度，别直接套模板
Go 里没有标准库拓扑排序函数，得自己写或封装。最常用的是 Kahn 算法（基于入度），它天然适合任务调度这类场景：节点是任务，边 u → v 表示 “u 必须在 v 之前完成”。你不能只 copy-paste 一个函数就完事——输入结构决定你怎么建图。
- 输入是
[][]int（如课程编号对）？用数组索引当节点 ID，inDegree用切片，下标即节点号 - 输入是
map[string][]string（如课程名依赖）？必须先收集全部 key 做节点集合，再映射到整数 ID 或直接用字符串处理入度 - 漏建某个节点的入度初始值（比如某课程没被任何其他课依赖，但也没出现在任何
prerequisites的dest位置）→inDegree[v]++会 panic 或漏统计
inDegree 数组/映射没初始化全，排序结果就少节点
Kahn 算法靠“入度归零才入队”驱动，如果某个节点压根没进 inDegree 映射或切片，它的入度就是 0（Go map 默认 0，切片默认 0），看似能进队，但后续遍历邻接表时可能 panic：这个节点根本不在 graph 键里，graph[u] 会返回 nil 切片，for _, v := range graph[u] 没问题；但如果你写了 len(graph[u]) 再循环，就会 panic。
- 安全做法：先扫一遍所有可能节点（比如
numCourses从 0 到 n-1，或for k := range prereqsMap+ 所有 value 中的字符串），显式初始化inDegree[k] = 0 - 用
map[int]int而不是切片？没问题，但检查环时不能用len(topoOrder) == len(graph)——graph可能不含所有节点（比如孤立节点），得用你一开始收集的完整节点集长度 - 常见错误现象：
topoOrder长度比预期少 1，且最后那个节点恰好是某个没前置依赖、也没被任何人依赖的“孤点”
检测环不能只看 len(topoOrder)
拓扑排序失败 = 图含环，但这个判断必须基于你定义的“全图节点集”，而不是邻接表键的数量。很多实现直接写 if len(topoOrder) != len(graph)，这在图不连通、有孤立点时一定出错。
- 正确做法：维护一个
allNodes切片或 map，明确包含所有应参与排序的节点（例如课程总数numCourses，或所有出现过的课程名） - 性能影响：多一次遍历收集节点，O(V+E) 不变，但避免了逻辑漏洞
- 容易踩的坑：用
map[string][]string输入时，只遍历 key 得到节点，却忘了 value 里的课程名也可能是新节点（比如"compilers": {"formal languages"}，但"formal languages"没作为 key 出现过）→ 必须双向扫描
DFS 版本看似简洁，但递归深了易栈溢出，别在大图上用
闭包 + 递归 DFS 实现（如 visitAll 匿名函数嵌套）写起来短，适合小规模配置解析，比如解析几十个 Go module 依赖或内部工具链任务。但它隐含两个风险：
- 无显式环检测：靠
seenmap 标记“正在访问中”状态才能判环，很多简版实现只标true/false，会把合法 DAG 误判为环 - 递归深度不可控：若依赖链超 1000 层（比如生成的代码构建图），Go 默认栈大小可能触发
runtime: goroutine stack exceeds 1000000000-byte limit - 实际建议：生产环境统一用 Kahn（BFS），队列用 slice 就够（
queue = queue[1:]性能可接受），加个maxNodes保护即可
真正麻烦的从来不是算法本身，而是你怎么定义“图的全集”——节点漏一个，环就检不出来；依赖方向搞反一次（prereq[0], prereq[1] 是 dest, src 还是 src, dest），整个顺序就颠倒。写完务必拿带环的小例跑一遍：[[0,1],[1,2],[2,0]]，看是不是返回空切片。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
