简介：经典农夫过河问题是人工智能与算法设计中的经典入门案例，这份文档围绕狼、羊、白菜、农夫渡河场景，面向计算机专业学生与算法初学者，完整梳理状态空间搜索、深度优先/广度优先搜索、动态规划、回溯与约束条件等核心思路。资源为1个doc文档，压缩包约371KB，内容以题目分析、状态四元组表示、操作符L(i)/R(i)定义、合法与非法状态约束、状态转移图构建及两类可行策略的逐步推演为主，并通过详细图解演示每一步农夫与物品的移动顺序，适合配合课程作业、实验报告或自学复习使用。已有3839人学习下载。文档从食物链约束出发，逐一列出所有会造成狼吃羊、羊吃白菜的危险状态，再通过递归/迭代搜索方式验证每一步是否安全，帮助读者理解如何将抽象逻辑问题转化为有限状态机并用搜索算法求解。对于正在学习搜索算法、图论、状态空间分析或准备人工智能相关实验的读者，这是一份思路清晰、便于快速上手的实用参考。
1. 狼羊菜农夫过河：被人工智能课程反复使用的状态空间搜索入门题
如果你翻开任何一本人工智能导论教材，搜索“农夫过河”或“狼羊菜”，大概率会在搜索算法那一章找到它。这道题表面上是脑筋急转弯，实际是经典的状态空间搜索问题：农夫、狼、羊、白菜四个对象的位置组合成状态，一次合法摆渡就是从当前状态跳到下一个状态，目标是在不触发食物链的前提下从(0,0,0,0)走到(1,1,1,1)。很多人工智能专业的学生第一次写搜索代码，就是用它来练DFS和BFS。我当年做人工智能大作业时，也把这道题当成算法实验的基础案例，后来发现它的价值远不止一次作业：理解清楚四元组建模、操作符设计和非法状态剪枝，再去看八数码、迷宫寻路、规划问题，基本是同一个套路——这也是人工智能学习路径里最典型的从理论到代码的过渡。
2. 把过河问题建模成四元组：状态、操作符与不合法状态的完整定义
任何搜索算法都需要三个东西：状态表示、状态转移、目标判断。这道题最常用的状态表示是四元组。这一章先把这三个零件逐一拆开，保证后面写代码时不会出现“状态定义对了，操作符写反了”这种低级错误。
2.1 为什么用四元组表示状态：左岸右岸只是0和1
状态S＝(L, J, M, N)，四个分量分别代表农夫（L）、狼（J）、羊（M）、白菜（N）所在的位置。约定0表示在左岸，1表示在右岸。初始状态是(0,0,0,0)，四个对象全在左岸；目标状态是(1,1,1,1)，全在右岸。
有的同学会问：为什么不直接用“左岸有哪些对象”来表示？那样也可以，比如用集合{农夫,狼,羊,菜}表示左岸，右岸就是全集减去左岸。但这个方案有一个隐患：农夫的位置必须单独记录，因为农夫是否在场决定了约束是否生效。集合表示虽然直观，但每次判断都要做差集运算，容易错。四元组把四个对象的位置并列写出来，每个分量就一个0或1，判断状态是否合法时直接读分量就行，程序里的if写起来也干净。
我在实际写状态搜索时，习惯把四元组当成一个长度为4的元组存入Python的tuple，这样可以直接作为字典的key去重。注意分量顺序要固定：农夫、狼、羊、菜。一旦换顺序，后续所有操作符和约束条件都得跟着改，这是最常见的翻车点之一。
整个搜索空间有多大？每位只有0和1两种取值，所以理论上有2^4=16个状态。去掉题目正文里列出的六个非法状态，真正可搜索的合法状态只有10个。正因为空间小，这道题才被反复用来做搜索算法的入门实验：你可以手动把整个状态转移图画出来，再对照代码结果，很容易发现自己的程序哪里写歪了。
2.2 操作符L(i)和R(i)的约束：船小只能带一样
题目说船每次只能带一样东西，农夫自己可以单独过河，也可以带狼、羊、菜中的任意一个。所以定义一组操作符：
- L(i)：农夫从当前状态向右岸（Left→Right，这里L表示执行方向，别和农夫分量的L混淆）移动，i=0表示农夫自己，i=1带狼，i=2带羊，i=3带白菜。
- R(i)：农夫从右岸向左岸移动，参数同样表示带谁或不带谁。
有人会把L和R理解成“左岸操作”和“右岸操作”，这就错了。L(i)表示农夫向右边（右岸）走，R(i)表示农夫向左边（左岸）走。写代码时，我一般用两个函数move_right(i)和move_left(i)来命名，避免和位置分量的L（农夫）冲突。
操作符的作用是产生新状态。以L(i)为例：执行前农夫必须在左岸，执行后农夫到右岸；如果i不等于0，那么对应对象也跟农夫一起到右岸；其他两个对象位置不变。用逐分量更新就行。R(i)同理，执行前农夫必须在右岸。
这里有个边界条件：农夫一次只能带一样东西，所以L(1)和L(2)不能同时执行。操作符本身“一次只改一个对象位置”已经天然保证了这一点。但要注意，操作符只描述“谁移动了”，不保证“移动后是否安全”。安全判断交给约束条件，也就是下一小节。
为什么i=0（农夫空手过河）也必须定义成操作符？我见过不少初学者只写带东西的动作，结果搜索永远解不出来。因为经典方案的第二步就是农夫空手从右岸返回左岸——不带羊回去，也不带狼，只把自己摆渡回去。没有这个空操作，状态就被困在右岸了。所以操作符集合必须包含“啥也不带”这个选项。
2.3 不合法状态清单：食物链是唯一剪枝条件
食物链关系是：狼吃羊，羊吃白菜。但前提是农夫不在场。所以约束条件必须写成“农夫不在的一岸，不能同时存在天敌关系”。题目正文里直接给出了六个不合法状态：
(1,0,0,1)、(1,1,0,0)、(0,1,1,0)、(0,0,1,1)、(1,0,0,0)、(0,1,1,1)。
我建议不要把这六个状态硬编码成集合，而是用规则生成。规则就一条：对任意一岸，如果该岸包含农夫就不管；如果不包含农夫，检查该岸是否同时包含(狼,羊)或者(羊,菜)。两个都算非法。这样写的好处是，以后题目改成“狼吃羊、羊吃菜、菜被猪拱”之类，只需要改规则列表。
代码里可以这样定义合法性检查：
def is_legal(state): L, J, M, N = state def unsafe(side): # 农夫不在side岸时，狼和羊或羊和菜同岸就非法 return (J == side and M == side) or (M == side and N == side) if L == 0 and unsafe(0): return False # 左岸无农夫，且左岸有食物链 if L == 1 and unsafe(1): return False # 右岸无农夫，且右岸有食物链 return True参数说明：is_legal接收一个四元组state，返回False表示非法，True表示合法。内部函数unsafe(side)检查指定岸是否同时存在狼羊或羊菜。这里直接用位置值比较，没有引入额外的物品编号，所以分量顺序一旦定下来，逻辑就很稳定。你可以手动测试几个状态：(1,0,0,1)的左岸有狼羊且农夫不在左岸，返回False；(1,0,1,0)的左岸只有狼和菜，右岸有农夫和羊，返回True。
这就是全部剪枝条件了。不要额外加“农夫不能和狼同船”之类的规则，题目里没有这个限制。农夫带狼、带羊、带菜都是允许的，只要到达后两岸都安全。如果你加了多余约束，搜索空间会被错误缩小，甚至把正确解也剪掉。
3. 用深度优先搜索找可行方案：递归回溯代码与访问标记防死循环
状态模型建好以后，剩下的就是交给搜索算法。深度优先搜索（DFS）是这道题最常见的解法。它的思路是：从初始状态出发，尝试所有可执行的操作符，对每个操作产生的新状态，先检查合法性，再检查是否访问过，如果都通过就继续递归下去，直到到达目标状态。因为DFS不保证找到最短路径，但一定能找到一条可行路径（如果存在）。
3.1 DFS的搜索顺序：先带羊还是先带菜？
题目分析里明确说了，第一次人只能带羊到右岸。因为如果先带狼，左岸剩羊和菜，羊会吃菜；先带菜，左岸剩狼和羊，狼会吃羊。所以唯一的合理第一步是L(2)，即带羊。这是人工推理的结果。但在程序里，我们没必要刻意调整操作符顺序，让DFS自然尝试所有操作，反正非法状态会被剪枝。不过操作符顺序会影响找到的第一条解长什么样。
我通常按i=0,1,2,3的顺序尝试。这样第一步会先试“农夫自己过去”，然后发现左岸狼羊菜没人管，非法；再试“带狼”，非法；再试“带羊”，合法，于是进入下一步。如果先试带菜，程序也会在后续步骤里绕回来，但第一条解可能不是最短的。如果你想快速看到一条可行解，可以把带羊（i=2）放在最前面，因为人工推理告诉我们第一步必须是它。
这里有一个技巧：操作符顺序既是DFS的搜索策略，也是调参入口。当题目变成“四人过桥”“传教士与野人”时，优先尝试哪一步往往取决于约束强度。我习惯把最不可能产生非法状态的操作放在最前面，能明显减少回溯次数。
3.2 伪代码与Python实现：从四元组到路径输出
DFS的递归实现非常简洁。我给出一个完整可运行的版本，包含状态合法性检查、访问记录和路径回放。
START = (0, 0, 0, 0) GOAL = (1, 1, 1, 1) def is_legal(state): L, J, M, N = state def unsafe(side): return (J == side and M == side) or (M == side and N == side) if L == 0 and unsafe(0): return False if L == 1 and unsafe(1): return False return True def move(state, direction, item): L, J, M, N = state # direction: 'R' 向右岸移动, 'L' 向左岸移动 delta = 1 if direction == 'R' else -1 L += delta if item == 1: # 带狼 J += delta elif item == 2: # 带羊 M += delta elif item == 3: # 带菜 N += delta # 越界说明农夫或物体不在可移动的岸边 if L not in (0, 1) or J not in (0, 1) or M not in (0, 1) or N not in (0, 1): return None return (L, J, M, N) def dfs_search(): path = [] visited = set() def dfs(state): if state in visited: return False visited.add(state) path.append(state) if state == GOAL: return True for item in [0, 1, 2, 3]: for direction in ['R', 'L']: nxt = move(state, direction, item) if nxt and is_legal(nxt) and nxt not in visited: if dfs(nxt): return True path.pop() return False if dfs(START): return path return None result = dfs_search() if result: for i, s in enumerate(result): print(f"step {i}: {s}") else: print("no solution")这段代码有几个细节需要说明。
首先，move函数里我用了一个方向参数direction和一个item参数。direction为'R'表示农夫向右岸移动，为'L'表示向左岸移动。delta分别为+1和-1，直接加到农夫分量上，如果带东西也加到对应对象上。这个写法比逐一判断“谁在哪一边”要干净得多。如果delta导致分量变成2或-1，move返回None，上层调用会因为if nxt而跳过该操作。
其次，dfs是递归函数。visited集合记录已访问状态，防止死递归。path列表保存当前路径，一旦找到目标就层层返回True，把完整路径带出来。回溯时path.pop()只会在本层所有尝试都失败后执行，这样path始终对应当前递归深度。
最后，搜索操作顺序是for item in [0,1,2,3]，内层再循环direction。这意味着对每个item，先试向右，再试向左。对于初始状态(0,0,0,0)，农夫在左岸，item=0 direction='R'，农夫变成1，状态(1,0,0,0)非法；item=0 direction='L'，农夫变成-1，返回None；item=1 direction='R'，状态(1,1,0,0)非法；item=2 direction='R'，状态(1,0,1,0)合法，进入递归。这就自动找到了正确第一步。
3.3 参数说明：为什么需要记录访问状态，避免死循环
很多新手写的DFS会漏掉visited。没有visited，程序会在两个状态之间来回跳：比如从(0,0,0,0)带羊到右岸变成(1,0,1,0)，再带羊回到左岸变回(0,0,0,0)，无限递归。加了visited之后，重复状态直接返回False，强制回溯。
注意visited的粒度是完整四元组，不是“狼羊菜的位置”三元组。为什么必须包括农夫位置？因为同样的三个物品位置，农夫在左还是右，决定了下一步能执行的操作完全不同。比如左岸有狼和菜，农夫在左，可以带狼过去；农夫在右，只能把东西带回来或自己回来。所以三元组无法唯一描述问题状态。如果你只记录J,M,N的位置，搜索会丢掉关键信息，可能找不到解，或者找到重复但本质不同的路径。
另一个容易被忽略的点是path.append和path.pop必须配对。我见过有人只append，不pop，结果路径越来越长，最后输出一个几十步的冗长解。正确做法是在递归进入前append，递归返回False后pop。如果找到目标，递归栈里所有状态已经保存在path里，直接返回True，不再pop，就能把完整路径带回。
我建议你把上面的代码跑一遍，输出应该是7步。记住，DFS找到的第一条解不一定是步数最少的，它取决于操作符顺序。要得到最短路径，得用广度优先搜索。
4. 用广度优先搜索找最短路径：队列实现与DFS的路径对比
DFS是从一条路走到黑，走不通再回头。广度优先搜索（BFS）则是层层推进：先探索所有一步能到达的合法状态，再探索两步能到达的，以此类推。由于它是按层扩展的，第一次到达目标状态的路径一定是步数最少的。农夫过河问题最经典的解是7步，BFS能稳定给出这个答案。
4.1 BFS保证最短路径的原理
BFS使用队列，队列天然具有先进先出特性。初始状态先入队。然后循环：从队首取出一个状态，生成所有合法后继状态，如果后继未被访问，就标记访问并入队。因为所有一步后继会在第一轮被遍历完，所有两步后继在第二轮被遍历完，所以第一个到达目标状态的节点，其深度就是最小步数。
要输出路径，还需要记录每个状态是从哪个状态来的。常见做法是用parent字典，保存“后继状态 -> 前驱状态”的映射。找到目标后，从目标开始反向回溯到起点，再把路径反转，就得到完整的操作序列。
注意，BFS同样需要visited集合。BFS中visited的作用不只是防死循环，更重要的是保证每个状态只入队一次。如果不标记，同一个状态可能被多个前驱重复生成，队列膨胀，虽然最终也能找到解，但时间空间复杂度会急剧上升。对于这个只有16个状态的小问题影响不大，但换成八数码、华容道就会爆炸。
4.2 队列实现与路径回溯
下面是使用Python标准库deque实现的BFS，和上一章的DFS共用同一个is_legal和move函数。
from collections import deque def bfs_search(): start = (0, 0, 0, 0) goal = (1, 1, 1, 1) queue = deque([start]) visited = {start} parent = {start: None} while queue: state = queue.popleft() if state == goal: # 反向回溯路径 path = [] while state is not None: path.append(state) state = parent[state] path.reverse() return path for item in [0, 1, 2, 3]: for direction in ['R', 'L']: nxt = move(state, direction, item) if nxt and is_legal(nxt) and nxt not in visited: visited.add(nxt) parent[nxt] = state queue.append(nxt) return None result = bfs_search() if result: for idx, state in enumerate(result): print(f"step {idx}: {state}")这个代码的关键点是parent字典和visited集合同步更新。在将nxt入队之前，就把nxt的parent设为state，并把nxt加入visited。这样能防止同一个nxt被另一个状态再次生成时重复入队。有人习惯先在队列里放状态，等出队时才标记visited，那会导致大量重复节点，甚至影响最短路径的正确性——因为同一状态可能被多个前驱以不同步数到达，先出队的未必是最短的那个。所以必须在入队时标记。
BFS的路径长度可以用一个动作序列来验证。运行上面代码，你会得到经典7步：
(0,0,0,0) -> (1,0,1,0) -> (0,0,1,0) -> (1,1,1,0) -> (0,1,0,0) -> (1,1,0,1) -> (0,1,0,1) -> (1,1,1,1)
对应动作依次是：带羊过河、空手返回、带狼过河、带羊返回、带菜过河、空手返回、带羊过河。注意第4步“带羊返回”是整个方案里最容易被人质疑的一步：好不容易把羊带过去，又要带回来？但为了让狼和羊不独处，这一步必不可少。
4.3 两种策略对比：DFS和BFS谁更适合这类题
从结果看，BFS能给最短路径，DFS则依赖操作符顺序。上一章我们的DFS由于操作符顺序正好也能得到7步，但如果你把操作符顺序改成先带菜，DFS可能先走出另一条对称路径，同样是7步。不过这是运气好。在一些更复杂的过河问题里，DFS很容易走出十几步的冗余路径，而BFS始终给出最优。
对比来说，BFS适合需要最优解的场景，缺点是内存占用大，因为要记录所有已访问状态的父指针。DFS内存占用小，代码也更简洁，适合“只要随便找到一条解”的约束满足问题。在人工智能课程里，这道题通常同时要求用两种方法实现，目的就是让你体会状态空间搜索与剪枝策略的区别。
如果你把题目改成“农夫可以带两样东西”或者“船最多载两个人”，DFS会非常容易陷入很长的冗余路径，而BFS仍然能找到最短。这就是我为什么建议：任何过河类问题，优先写BFS，除非题目明确要求“任意解一”。
5. 避坑指南：状态搜索中五个常见翻车现场与修复方法
我见过太多人在这个简单问题上踩坑。下面的五条，是我自己以及周围同学真实犯过的错，按“现象→原因→解决”列出来。每一条我都专门跑过复现，确认是高频错误。建议你在写代码前先看一眼，能省下至少一个下午的调试时间。
5.1 农夫自己过河的操作被漏掉
现象：搜索程序跑出来只有带东西的动作，没有任何“农夫空手返回”的步骤，最后解不出来。你甚至可能在队列里等不到目标状态，因为中间状态根本生成不出来。
原因：很多新手在定义操作符时只写“带狼”“带羊”“带菜”，忘了题目里农夫可以独自划船返回。实际上每个来回之间往往需要空船返回，比如带羊过去后，农夫必须空手回来，才能把狼带过去。没有i=0这个操作，搜索空间就断了。
解决：在操作符集合里加入“农夫自己”这一项，对应L(0)和R(0)。在move函数里，item=0时只移动农夫分量。这个操作合法，而且在很多步骤中必不可少。检查你的代码，如果move函数里连一个“只移动L分量”的分支都没有，那多半就漏了。还有一种变体题要求“农夫必须带一样东西才能划船”，那种情况才允许去掉i=0，但我们这道题里i=0是刚需。
5.2 状态去重只去重物品位置，忘记农夫位置
现象：程序运行结果路径中出现了重复的“物品组合”，比如左岸是狼和菜，但有时农夫在左，有时在右，程序却认为已经访问过，直接跳过，导致找不到解或解不完整。
原因：visited集合里存的是元组(J,M,N)，而不是(L,J,M,N)。对于同一个物品分布，农夫位置不同，可达的操作完全不同，不能视为等价的同一状态。比如左岸有狼和菜，农夫在左时他可以带狼去右岸；农夫在右时他只能先把羊送回左岸。如果把这两个状态混为一谈，搜索就会丢失大量分支。
解决：始终使用完整四元组作为状态标识。如果你用字典表示状态，键也必须是四元组。记住，状态的定义必须包含所有影响决策的信息，农夫位置就是其中之一。用Python的set存元组，天然支持四元组，不需要额外处理。千万别为了省一点空间用三元组，这点内存省出来毫无意义，带来的bug却很难查。另外，如果你用列表而不是元组存储状态，set会报不可哈希，这也是新手常踩的附带坑，记得用tuple。
5.3 操作符方向写反：R(i)不是L(i)的简单取反
现象：初始状态(0,0,0,0)下，程序先尝试R(0)，结果农夫变成-1，被当作非法状态丢弃，最终搜不出解。或者更隐蔽的情况：程序跑出了路径，但路径上的方向都是反的，比如“带羊过河”实际变成了“从右岸带羊回左岸”，而状态却因为越界检查不严而通过了。
原因：L和R的定义混淆。有人把L(i)理解成“从左岸出发”，把R(i)理解成“从右岸出发”，而不是“向右岸移动”和“向左岸移动”。初始状态农夫在左岸，可以执行的是向右岸移动，即L(i)，而不是R(i)。
解决：用move函数统一处理。方向参数direction='R'表示向右岸走，direction='L'表示向左岸走。在move内部，直接检查目标位置是否在0..1范围内，越界即返回None。不要在操作符名上纠结，用正负数表示方向更直观。我自己的习惯是只写move(state, direction, item)，把方向判断全放在move里，上层调用时永远只生成'R'和'L'两种字符串，从根源上杜绝“左岸操作”和“右岸操作”的语义混乱。
5.4 约束条件漏掉“农夫不在场”这个前提
现象：程序把(0,0,0,0)就判定为非法状态，因为左岸有狼羊菜，按“狼吃羊、羊吃菜”规则确实会出事，但此时农夫明明在左岸看着它们。
原因：约束条件的正确写法是“如果某一岸没有农夫，且该岸同时存在狼羊或羊菜，那么非法”。把“没有农夫”忽略了，就会误伤所有初始状态和许多中间状态。这道题有一个隐含前提：农夫在场时，食物链关系不会触发。狼不敢吃羊，羊不敢吃菜，因为农夫会阻止。
解决：在is_legal函数里，先检查农夫所在位置，只对农夫不在的那一岸做食物链检查。具体参见第二章的is_legal实现。一个简单的记忆方法是：非法状态只会出现在“农夫不在的那一侧”。所以你可以把判断写成：if L == 0 and unsafe(0): return False; if L == 1 and unsafe(1): return False。如果题目换成了“狼羊菜两岸都受监管”之类的变体，才需要改变逻辑，但本题不是。
5.5 把菜和羊的位置搞混，导致路径看似合理实际违反规则
现象：某次作业里我输出了一条“看似可行”的路径，但仔细核对发现第3步把菜放到了右岸和羊同侧，而农夫在左岸，程序却判为合法。当时我还以为是搜索算法错了，最后定位到是move函数里物品编号映射错位。
原因：在move函数里，物品编号映射错位。比如把SHEEP映射到3，CABBAGE映射到2，而is_legal里仍然按2是羊、3是菜来判断。两处映射不一致，产生了一个“平行宇宙”里的合法路径。这种bug不会报错，只会给你一条不可能的过河记录。
解决：把物品编号统一到一个常量定义里，并在move和is_legal中引用同一份常量。不要在不同函数里重复写数字。代码里最好写WOLF=1, SHEEP=2, CABBAGE=3，然后全部用符号判断。这样即使要扩展新物品，也只需要改这一处。或者像第二章那样，直接用位置值0/1比较，根本不引入物品编号，从根上避开这个坑。
这五条里，第2条和第5条最阴险。它们不会让程序报错，而是给你一条看似正确的错误路径。所以每次搜索完，一定要做路径合法性验证——这就是第六章要讲的内容。另外，如果你真的把所有坑都踩了一遍，也不要灰心，这种题目本来就是用来练调试的，踩坑越早，后面写复杂搜索越稳。
6. 验证与可视化：状态转移图手绘技巧和自动化断言
这一章分享两个我一直在用的验证手段。别看题目简单，养成验证习惯后，处理复杂搜索题能少走很多弯路。
6.1 手工画出状态转移图，核对每条边
从初始状态(0,0,0,0)出发，逐步展开合法转移。例如第一步唯一合法是带羊过河到(1,0,1,0)；从那里可以空手回(0,0,1,0)，或者带羊回起点。继续画下去，你会得到一条清晰的7步链。手画图的价值在于，它能暴露代码里的方向错误：比如从(1,1,1,0)本应带羊回左岸，如果程序输出的是带菜回，你在图上立刻就能发现。
6.2 用断言自动验证路径合法性
我更常用的是自动化检查。搜索程序给出路径后，用一个断言脚本逐条验证：
def validate_path(path): assert path[0] == (0, 0, 0, 0), "起点不对" assert path[-1] == (1, 1, 1, 1), "终点不对" for i in range(len(path) - 1): cur, nxt = path[i], path[i + 1] assert cur[0] != nxt[0], f"第{i}步农夫没动" diff = [cur[j] != nxt[j] for j in range(4)] assert sum(diff) in (1, 2), f"第{i}步移动对象数错误" assert is_legal(nxt), f"第{i}步到达非法状态: {nxt}" print("路径验证通过")它检查三件事：起点终点正确、农夫每一步都动、移动后状态合法。路径里任何违反食物链的状态都会立刻抛错，并定位到具体是哪一步。
6.3 一个压箱底的习惯：任何搜索题先做状态合法性检查
自从被“菜羊位置互换”坑过之后，我每次做搜索题都固定走三遍：先跑状态合法性单元测试，把16个状态逐一过一遍，确认只有6个非法；再跑BFS，确认最短路径步数；最后用validate_path验证输出路径。复杂题目也一样，只是状态数量变多而已。
这个习惯帮我省掉了无数深夜调bug的时间。状态空间搜索的难点从来不是算法本身，而是状态定义和约束传递是否一致。把检查做成自动化，你的心智负担会小很多。如果你把上面的代码存成search.py，配合validate_path一起用，以后做任何状态搜索题都能少走弯路。希望帮到你。
本文还有配套的精品资源，点击获取
