3道solved高频题，手写实现破局

看了一堆教程还是不会写项目？这种挫败感我太熟悉了。

你跟着视频敲代码没问题，一旦关掉视频让你从零开始，脑子就一片空白。

问题出在你只做了“复现”，没做“手写实现”。

今天不讲虚的，直接拆解3道面试必考的solved级难题。

我们用“手写实现”的方式，把底层逻辑扒开揉碎。

哪怕你基础薄弱，也能跟着走完整个思考路径。

一句话原理：状态机与边界控制

这三道题的核心，都指向同一个底层原理：状态管理与边界条件的精确控制。

很多初学者写代码，喜欢凭直觉。

数据来了就处理，处理完就结束。

但真正的工程级代码，必须像精密仪器一样，每一步都有明确的“状态定义”。

什么是状态？

就是程序在某一时刻，对输入数据的“认知”。

比如处理字符串，你是处于“正在读取数字”的状态，还是“遇到分隔符”的状态？

再比如处理数组，你是处于“寻找最小值”的阶段，还是“回溯更新”的阶段？

solved级面试题，往往不是考你算法复杂度多高，而是考你能否把模糊的业务逻辑，拆解成清晰、无歧义的状态流转。

这就是为什么你看完教程觉得懂了，一上手就废。

因为教程给你的是“结果”，没给你“推导过程”。

你现在需要的，不是更多的代码片段，而是建立自己的“状态机思维”。

类比解释：像老练的厨师处理食材

想象你是一位刚入行的厨师。

老板给你一筐乱七八糟的蔬菜，让你做一道“炒时蔬”。

新手厨师怎么做？

拿到菜就切，切完就下锅，调料随便放，炒熟就出锅。

结果呢？

有的老了，有的生了，味道咸淡不均，甚至可能把不相容的食材混在一起，炸了锅。

老厨师怎么做？

第一步，分拣。把菜分成叶菜、根茎、菌菇三类。这是“状态定义”。

第二步，预处理。根茎类焯水去生味，叶菜控干水分。这是“状态转换”。

第三步，火候控制。先炒难熟的根茎，再下易熟的叶菜，最后放菌菇提香。这是“边界控制”。

第四步，出锅时机。闻到香气、看到颜色变化，立刻关火装盘。这是“终止条件”。

你看，老厨师脑子里有一套完整的“流程脚本”。

他不需要每次做菜都重新思考，因为他的肌肉记忆和逻辑思维已经固化为“状态机”。

编程也是同理。

你手写实现solved题目时，脑子里要有这套“厨师脚本”。

输入数据进来，先“分拣”（数据清洗）。

然后“预处理”（初始化变量）。

接着“火候控制”（核心循环逻辑）。

最后“出锅”（返回结果）。

每一个步骤，都要问自己：现在处于什么状态？下一个状态是什么？什么情况下必须停止？

想清楚这四个问题，代码自然就顺了。

源码/伪代码片段：手写实现LeetCode 226题

我们以一道经典的solved高频题为例：翻转二叉树。

这题看似简单，但它是理解递归状态转移的最佳模型。

很多人写出来是这样：

def invertTree(root):if root:root.left = invertTree(root.right)root.right = invertTree(root.left)return root

代码没错，但你知道它“为什么”对吗？

如果你只能背下这段代码，换个稍微变形的题目，你就懵了。

我们用手写实现的方式，一步步拆解它的状态逻辑。

第一步：定义终止状态（Base Case）

树为空，或者节点为叶子节点时，不需要翻转，直接返回。

这就是“出锅时机”。

if not root:return None

第二步：定义当前状态的操作（Recursive Case）

当前节点非空，我们需要交换它的左右子树。

但注意，这里有个陷阱。

你不能直接 root.left, root.right = root.right, root.left。

因为 root.left 和 root.right 本身也是树，它们内部的节点也需要翻转。

所以，我们需要先对左子树调用函数，得到翻转后的左子树。

再对右子树调用函数，得到翻转后的右子树。

最后，把这两个“已经翻转好的子树”，挂到当前节点的左右位置上。

第三步：状态转移的代码体现

# 伪代码思路
current_left_inverted = invertTree(root.left)  # 获取左子树翻转后的状态
current_right_inverted = invertTree(root.right) # 获取右子树翻转后的状态root.left = current_right_inverted  # 交换：原右子树变左
root.right = current_left_inverted  # 交换：原左子树变右return root # 返回当前节点，它现在已经是翻转后的根了

你发现了吗？

每一行代码，都对应着“状态”的变化。

invertTree(root.left) 是一个“子状态”的求解过程。

当子状态求解完毕，它作为一个“已解决的值”，被传递回父状态。

这就是递归的本质：把大问题拆解成小问题，小问题的解是父问题的一部分。

很多初学者看不懂递归，是因为他们试图用“线性思维”去理解“树状思维”。

线性思维是：第一步，第二步，第三步。

树状思维是：先搞定左边，再搞定右边，最后合并。

你不需要知道左边内部怎么搞定的，你只需要相信：invertTree 函数能帮你搞定任意一棵子树。

这就是“信任契约”。

在官方文档中，递归函数的设计原则就是“假设子调用是正确的，只关注当前层逻辑”。

这一点，Python官方文档在描述函数调用栈时也有隐含体现。

流程描述：从输入到输出的状态流转

我们把上面的逻辑，用一个文本流程图表示出来。

假设输入是一棵简单的二叉树：

    4/ \2   7/ \   / \
1   3 6   9

阶段一：初始化

root 指向节点 4。

状态：当前处理根节点。

阶段二：左子树递归

调用 invertTree(root.left)，即处理节点 2。

节点 2 非空，继续递归。

调用 invertTree(2.left)，即处理节点 1。

节点 1 是叶子，返回 1。

调用 invertTree(2.right)，即处理节点 3。

节点 3 是叶子，返回 3。

回到节点 2，执行交换：

2.left 变为 3，2.right 变为 1。

返回节点 2（此时子树已翻转）。

阶段三：右子树递归

调用 invertTree(root.right)，即处理节点 7。

节点 7 非空，继续递归。

调用 invertTree(7.left)，即处理节点 6。

节点 6 是叶子，返回 6。

调用 invertTree(7.right)，即处理节点 9。

节点 9 是叶子，返回 9。

回到节点 7，执行交换：

7.left 变为 9，7.right 变为 6。

返回节点 7（此时子树已翻转）。

阶段四：根节点合并

回到根节点 4。

拿到左子树翻转后的结果（根为2的树）。

拿到右子树翻转后的结果（根为7的树）。

执行交换：

4.left 指向原来右边的树（根为7）。

4.right 指向原来左边的树（根为2）。

返回节点 4。

最终输出树结构：

    4/ \7   2/ \   / \
9   6 3   1

你看，整个过程就像剥洋葱。

一层一层地剥，直到最里面（叶子节点），然后再一层一层地裹回来。

每一层剥的时候，都要做“交换”这个动作。

这就是状态流转的完整闭环。

你在手写实现时，必须能在脑海里模拟这个过程。

如果模拟不出来，说明你对递归的“调用栈”理解不深。

这时候，建议画树状图，手动模拟一遍。

不要嫌麻烦，这是从“看懂”到“会写”的关键一步。

实战验证：如何在项目中应用这套思维

这套“状态机+递归/迭代”的思维，不仅仅用于刷题。

它在实际项目中无处不在。

比如，你开发一个前端组件，需要处理嵌套的JSON数据。

或者，你写一个后端服务，需要处理递归的目录权限校验。

又或者，你做一个数据爬虫，需要遍历多层级的网页链接。

这些场景，本质上都是“树状结构”或“图状结构”的处理。

你如果只会用 for 循环和 if 判断，遇到深层嵌套就会写得很乱。

但如果你用“状态机”思维，代码就会非常清晰。

实战案例：处理嵌套配置

假设你有一个配置对象，结构如下：

{"database": {"host": "localhost","options": {"port": 3306,"ssl": {"enabled": true}}},"server": {"port": 8080}
}

你需要写一个函数，找出所有 key 中包含 "port" 的值。

新手写法：

def find_ports(config):results = []for key, value in config.items():if "port" in key:results.append(value)if isinstance(value, dict):results.extend(find_ports(value))return results

这段代码能用，但状态不清晰。

优化后的“状态机”写法：

def find_ports(config, path=""):results = []for key, value in config.items():current_path = f"{path}.{key}" if path else key# 状态1：匹配到目标Keyif "port" in key.lower():results.append((current_path, value))# 状态2：遇到嵌套字典，进入子状态if isinstance(value, dict):sub_results = find_ports(value, current_path)results.extend(sub_results)# 状态3：遇到列表，遍历列表元素elif isinstance(value, list):for i, item in enumerate(value):if isinstance(item, dict):sub_results = find_ports(item, f"{current_path}[{i}]")results.extend(sub_results)return results

你看，我显式地定义了三种状态：

1. 匹配状态：Key符合规则，记录结果。
2. 递归状态：Value是字典，下钻。
3. 迭代状态：Value是列表，横向遍历。

每一种状态都有明确的处理逻辑，互不干扰。

这样写，扩展性极强。

如果以后要增加“如果Value是字符串，也检查”的逻辑，你只需要加一个 elif 分支，不会影响其他状态。

这就是“手写实现”带来的思维升级。

你不再是“堆砌代码”，而是在“构建系统”。

结尾：你的项目里踩过这个坑吗？

看到这里，你可能觉得有点抽象。

没关系，理论只有落地，才能变成你的能力。

我建议你拿一道最近让你头疼的solved题，或者一个实际项目中的复杂逻辑，用今天讲的“状态机”思维，重新手写一遍。

不要看答案，不要查文档，就凭你的脑子，画出状态流转图，然后写代码。

写错了？没关系。

错了，才知道哪里卡住了。

这才是真正的学习。

教程只能给你地图，路得你自己走。

手写实现，就是那条路。

你在项目里踩过这个坑吗？是递归写死了，还是状态没控制好导致Bug频发？评论区聊聊，看看有没有和你一样的人。