排查Python骑士走法程序隐藏Bug 定位合法走步生成逻辑问题

走步生成片段的验证 #

你怀疑的两段负责生成合法骑士走法的代码逻辑本身没有问题：

• 通过itertools.product组合出的坐标，完整覆盖了骑士标准走法的8种偏移：纵向±1搭配横向±2、纵向±2搭配横向±1
• 边界过滤判断x >= 0 and y >= 0 and x < 8 and y < 8可以正确筛出落在棋盘外的无效走步
  真正的问题出在其他核心链路里。

核心问题定位 #

坐标定位循环的条件硬伤 #

原代码把棋格编号转成棋盘坐标的循环写法存在逻辑错误：

while src:
    if r_s <= src <= r_e:
        # 匹配列坐标
        break
    str_r += 1
    r_s += 8
    r_e += 8

这里直接把src的值作为循环判断条件，意味着只要src是0（棋盘左上角的合法起始位置），整个坐标定位循环会直接跳过，完全不执行分支内的匹配逻辑。现在代码看起来能正常处理src=0的场景，只是因为初始变量str_r=0、str_c=0刚好和(0,0)的坐标值重合，属于巧合性正确，一旦初始变量值调整就会完全失效。
正确的循环应该用while True做无限匹配，找到对应行坐标后再break退出，绝对不能把src的数值本身作为循环的终止判断条件。

缺失初始边界判断 #

原代码完全没有覆盖src == dest的场景：按照最短路径计算规则，起点和终点重合时应该直接返回0步，但当前代码从初始步长1开始遍历，永远无法在初始轮检测到起点和终点重合的情况，会直接进入无限循环。

BFS遍历逻辑的结构性缺陷 #

原代码用层序遍历算最短路径的核心逻辑缺失了最关键的已访问节点标记：

• 每一轮更新遍历池时，没有把之前已经到达过的坐标排除，会把上一轮、上上轮已经走过的节点重新纳入下一轮遍历，既存在无限绕圈的风险，也会因为重复入列拉长计算流程
• 没有已访问标记，无法保证第一次检测到终点时得到的步数是真正的最短路径

可落地的修复方案 #

• 修正坐标定位循环：把while src改成while True，保证src=0时也能正常完成坐标匹配
• 补全初始判断：函数开头先增加判断，如果src == dest，直接返回0步
• 增加全局已访问集合：每遍历到一个坐标就将其加入已访问集合，下一轮生成走步时自动跳过已访问的坐标，避免重复遍历和绕圈
• 简化坐标转换逻辑：移除硬编码的棋盘矩阵和循环查找逻辑，直接通过r = 棋格编号 // 8、c = 棋格编号 % 8的数学计算快速得到对应坐标，减少冗余代码

内容的提问来源于stack exchange，提问作者ALI AHMAD