应使用 collections.deque 而非 list 模拟队列，因 list.pop(0) 时间复杂度为 O(n)，而 deque.popleft() 为 O(1)；BFS 频繁出入队时性能差异显著，尤其在大规模稀疏图中。
为什么用 collections.deque 而不是列表模拟队列
用 list 的 pop(0) 做出队操作，时间复杂度是 O(n)，因为要移动后面所有元素；而 deque 的 popleft() 是 O(1)。BFS 每次都要频繁出队入队，尤其图大时，性能差距明显——比如遍历 10 万节点的稀疏图，list 可能卡住几秒，deque 通常在毫秒级。
常见错误现象：list.pop(0) 在循环中越跑越慢，CPU 占用高但进度停滞；或者误用 append() + pop()（这实际是 DFS 行为）。
- 始终用
from collections import deque，别手动维护 list 队列 -
deque初始化支持可迭代对象，如deque([start_node]) - 不要调用
deque.appendleft()或pop()，BFS 必须保证先进先出
bfs 函数里怎么写才算正确入队和访问顺序
BFS 的核心是「发现即入队，出队即访问」。很多人把「访问」和「加入队列」混在一起，导致重复访问或漏节点。关键点：只有当节点未被访问过，才把它加入 deque，且必须在入队**后立刻标记已访问（比如加进 visited 集合），不能等到出队时再标记。
否则会出现：同一节点被多次加入队列（比如 A→B、C→B，B 还没出队就被重复入队两次），造成冗余计算甚至死循环（无向图中尤其明显）。
立即学习“Python免费学习笔记（深入）”；
- 用
visited = set()记录已访问节点，初始化时加入起点 - 每次从
queue.popleft()取节点，立即处理（比如打印、收集） - 对每个邻接节点
neighbor，仅当neighbor not in visited时，执行visited.add(neighbor)和queue.append(neighbor)
from collections import deque
def bfs(graph, start):
visited = {start}
queue = deque([start])
result = []
while queue:
node = queue.popleft()
result.append(node)
for neighbor in graph.get(node, []):
if neighbor not in visited:
visited.add(neighbor)
queue.append(neighbor)
return result
处理非连通图或空图时容易忽略的边界情况
真实图数据常有孤立节点、空邻接表、甚至 None 键。如果直接写 graph[node]，遇到缺失键会抛 KeyError；如果图为空（graph = {}）且 start 不在其中，也会崩。
使用场景：读取 JSON 构建的图、网络拓扑快照、依赖关系映射——这些输入往往不规范。
- 统一用
graph.get(node, [])替代graph[node]，避免 KeyError - 在函数开头检查
start是否在图中有效：若start not in graph and not graph.get(start)，可提前返回空列表或抛自定义异常 - 若需遍历整个非连通图，不能只从一个
start开始，得外层补一层for node in graph循环，配合全局visited
如何扩展支持路径记录或层级信息
纯节点遍历只是基础。工程中更常需要知道「从起点到某节点的最短路径」或「当前在第几层」。这时不能只存节点值，得在队列里存元组。
性能影响：存元组略微增加内存，但比事后重建路径高效得多；层级计数若用额外变量控制（比如每层结束加个哨兵），比每次查 len(queue) 更稳定。
- 记录路径：队列存
(node, path)，初始为deque([(start, [start])])，扩展时生成(neighbor, path + [neighbor]) - 记录层级：用
level = 0，每轮while循环开始前设for _ in range(len(queue)):，内部不新增节点，本轮结束后level += 1 - 避免在循环内反复调用
len(queue)判断是否换层——它在deque上是 O(1)，但语义不清，易被误读为 O(n)
deque 的操作习惯和访问标记时机里，改错一次比重写三次还管用。 
