LeetCode单词搜索：为何Python range()判断边界失效？

核心原因：range()判断的性能问题与递归逻辑的隐藏缺陷 #

首先明确：当range(rows)使用默认起始值0、步长1时，row not in range(rows)逻辑上完全等价于row < 0 or row >= rows，两者都能正确识别越界的行/列。那你的单词搜索DFS代码为何会出现无限循环？

1. 高频递归下的性能差异 #

range()对象的in操作虽然是O(1)的，但每次判断都需要进行范围计算，而直接数值比较（row <0 or row >=rows）是更底层的运算，速度更快。当单词长度较长、矩阵规模较大时，DFS会产生大量递归调用，高频的in操作会导致程序执行速度急剧变慢，看起来像是陷入了无限循环——换成直接数值比较后，判断效率提升，程序能在合理时间内终止。

2. 递归路径的残留问题（与边界判断无关，但影响执行逻辑） #

你的DFS代码中存在一个隐藏的路径处理缺陷：

path.add((row, col))
bottom = dfs(row + 1, col, ind + 1)
top = dfs(row - 1, col, ind + 1)
right = dfs(row, col + 1, ind + 1)
left = dfs(row, col - 1, ind + 1)
path.remove((row, col))
return bottom or top or right or left

Python的or运算符是短路求值：如果bottom返回True，后续的top/right/left递归不会执行，同时path.remove((row, col))也会被跳过。这会导致当前(row, col)一直留在path集合中，后续其他递归分支访问该位置时会直接返回False，进一步拖慢程序执行，加剧“无限循环”的假象。

3. 岛屿数量BFS代码中range()判断有效的原因 #

在岛屿数量的BFS代码中，new_row in range(rows)的判断是在将新坐标加入队列前执行的，只有合法坐标才会进入队列，不会产生大量无效判断。同时BFS的递归深度远低于DFS，in操作的性能影响可以忽略，因此不会出现问题。

修复建议 #

1. 优先使用直接数值比较判断边界，兼顾性能与可读性。
2. 修复路径残留问题，确保无论递归是否返回True，都能移除当前路径：

path.add((row, col))
try:
    bottom = dfs(row + 1, col, ind + 1)
    top = dfs(row - 1, col, ind + 1)
    right = dfs(row, col + 1, ind + 1)
    left = dfs(row, col - 1, ind + 1)
    return bottom or top or right or left
finally:
    path.remove((row, col))

内容的提问来源于stack exchange，提问作者Rachel Kim