Python BFS开发：循环内追加队列元素时range(len(队列))为何不改变循环次数

核心结论 #

• len(rotting_oranges) 仅在for循环启动的初始阶段被执行一次，结果作为固定边界传入range()，循环执行过程中不会重新计算队列长度。
• 之前的认知误差来源于混淆了两个独立的特性：deque对象本身的长度动态变化、函数调用的单次求值时机。

执行流程拆解 #

1. for循环触发时，Python会按照表达式书写顺序，从左到右依次计算：
   • 先执行len(rotting_oranges)，拿到当前时刻队列长度的整数值
   • 用这个整数值生成对应的range可迭代对象
   • 整个计算流程在循环体第一行代码执行前就全部完成，循环启动后不会再回头计算最初的表达式
2. range对象的内部逻辑：
   • 它不会持有生成它时传入参数的引用，只是把初始算出来的整数值存成自己的内部终止边界
   • 迭代时只会逐次从初始值开始递增，碰到预先存好的终止边界就停止，全程不会查询原始队列的实时状态

代码层面的直观验证 #

from collections import deque
q = deque([(0,0), (0,1)])  # 初始队列长度为2
for i in range(len(q)):
    print(f"第{i}次循环，当前队列长度：{len(q)}")
    q.append((1,0))  # 每次循环往队列里加元素
# 实际输出：
# 第0次循环，当前队列长度：2
# 第1次循环，当前队列长度：3

• 上面的代码总共只会执行2次循环，哪怕第二次循环结束时队列长度已经变成3，也不会触发第三次循环。

对BFS代码逻辑的实际影响 #

• 实现的层序遍历逻辑，恰好利用了这个特性：
  • 进入处理每一分钟的while循环时，队列里存储的全是上一分钟已经腐烂的橘子
  • 此时计算的队列长度，就是当前需要处理的同层节点总数
  • for循环按固定次数把当前层的节点全部弹出处理，处理过程中新感染的橘子被追加到队列末尾，因为循环边界固定，这些新元素不会被算入当前层的处理范围
  • 当前层处理完后退出for循环，回到外层while重新计算队列长度，刚好对应当前队列里存储的下一层节点，实现按层分割、按分钟计数的效果
• 如果len()在循环中实时生效，反而会破坏层序逻辑：循环会一直把新追加的节点也处理完，无法区分每一层对应的时间步长。

内容的提问来源于stack exchange，提问作者David Zheng