必须用container/heap实现dijkstra的优先队列，因其支持o(log v)堆操作；若用sort.slice模拟则退化为o(v²)，千级节点即卡顿，且易因缺少懒删除、索引维护或类型断言错误导致结果错、性能崩。
Go 语言实现 Dijkstra 算法必须用 container/heap 做优先队列，否则时间复杂度退化到 O(V²)，一过千级节点就明显卡顿。
为什么不能直接用 slice 模拟最小堆
Go 没有内置的最小堆类型，container/heap 是唯一标准库支持的可定制堆。自己手写堆逻辑容易出错，尤其在 Pop 后忘记重置 index 字段，会导致后续 Push 或堆内元素位置错乱；更常见的是漏掉“延迟删除”判断（即取出堆顶时发现 dist[u] != item.dist），让已更新过的旧条目反复参与松弛，结果错、性能崩。
- 必须为堆中每个
*Item维护index int字段，并在Swap和Push里同步更新 - 每次
heap.Pop后要立刻检查if item.dist != dist[item.vertex]，不等就continue - 不要复用
Item实例：每次Push都应新建&Item{...}，否则多个引用指向同一内存会覆盖距离值
container/heap 的正确初始化和 Push/Pop 模式
优先队列不是“把所有节点塞进去再开始跑”，而是动态增删：Push 只在松弛成功时触发，初始只入堆源点；Pop 返回的是指针，必须解引用取 .vertex 和 .dist。典型错误是把 heap.Pop(&pq) 当成值拷贝来用，实际它返回 interface{}，不强制类型断言会 panic。
- 初始化：
pq := make(PriorityQueue, 0); heap.Init(&pq); heap.Push(&pq, &Item{vertex: start, dist: 0}) - Pop 后断言：
item := heap.Pop(&pq).(*Item)，不是item := pq[0]; heap.Pop(&pq) - Push 前必须确保
dist[v]已被更新，否则堆里存的是过期值
邻接表结构怎么设计才不拖慢松弛操作
图用 map[int]map[int]int 看似灵活，但遍历邻居时多一层哈希查找，且无法保证顶点编号连续——而 Dijkstra 要频繁索引 dist[v] 数组。工程中更稳妥的是用切片索引：顶点编号从 0 到 n-1，graph[u] 是 []Edge，其中 Edge 是 struct{ to, weight int }。
- 避免用
map[int][]Edge：稀疏图下内存浪费小，但随机访问慢；graph定义为[]([]Edge)，长度等于顶点数 -
Edge不要嵌套指针或大结构体，否则range graph[u]复制开销大 - 如果顶点 ID 是字符串（如城市名），先做
map[string]int映射到整数 ID，Dijkstra 全程用整数运算
dist 数组初始化用 math.MaxInt64 还是 math.MaxInt32
取决于边权范围。若权重可能超过 2³¹−1（比如地理距离用米为单位的超长路径），必须用 int64 和 math.MaxInt64，否则松弛时 dist[u] + weight 溢出变负数，算法彻底失效。但多数场景用 int（在 64 位系统上等价于 int64）加 math.MaxInt64 更安全。
- 别用
-1表示无穷大：比较时要写if dist[v] == -1 || dist[u]+w ，逻辑臃肿且易漏判 - 初始化后立刻设
dist[start] = 0，别依赖堆里那个0值去覆盖——堆只是辅助，dist数组才是事实来源 - 输出前检查
dist[v] == math.MaxInt64再决定是否显示 “inf”，避免打印巨大负数
最易被忽略的一点：Dijkstra 不处理负权边，但 Go 实现里不会主动校验输入图。如果你传入含负权的 graph，算法仍会跑完，但结果无效——没有运行时报错，只有业务侧路径异常时才暴露问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
