栈：Cmd+Z 和「爆栈」的秘密
后进先出：撤销键、函数调用、Agent 的子任务都靠它。亲手压栈弹栈，再看一次没写终止条件的递归是怎么把栈压爆的
本页解决的问题
先给结论「栈：Cmd+Z 和「爆栈」的秘密」要解决的关键问题是什么？
后进先出：撤销键、函数调用、Agent 的子任务都靠它。亲手压栈弹栈，再看一次没写终止条件的递归是怎么把栈压爆的
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
左边是个迷你文档，用四个按钮随便折腾它。留意右边：你的每一步操作都被压成一张牌，叠在「操作栈」上——后做的压在上面。折腾够了，连按几下「Cmd+Z 撤销」，看看它撤的顺序。
📄 迷你文档
随便操作，别心疼
🥞 操作栈
每步操作压一张牌，最上面 = 最近一步
你让 AI「做晚饭」，它做到一半要切菜，切菜切到一半刀钝了要磨刀……每次「暂停手头的事去干别的」，程序都会把当前进度压进一个栈里。看下面的动画（滚到这里会自动播一遍），留意每个任务完成后，程序是怎么自动找回上一个任务的。
栈的容量是有限的。下面这个函数自己调用自己（这叫递归），左边是代码，右边是调用栈。先不勾终止条件跑一次，看看会发生什么；再勾上跑一次对比。
「先玩 · 撤销键的真身」为什么要看操作
「左边是个迷你文档，用四个按钮随便折腾它。」把结构落到了一个具体动作。这里真正要比较的不是名词谁更高级，而是数据如何被放置，以及最常发生的操作需要走多远。
读懂结构，要同时看访问方式和变化方式
「你让 AI「做晚饭」，它做到一半要切菜，切菜切到一半刀钝了要磨刀……每次「暂停手头的事去干别的」，程序都会把当前进度压进一个栈里。」揭示了一个容易被忽略的取舍：按位置读取、按键查找、从两端进出、插入新元素和遍历关系，适合的组织方式并不相同。一个结构在某个操作上很快，不代表它在所有操作上都快。
- 栈 = 一摞盘子 ：只从顶端放和拿，后进先出（LIFO）
- 撤销键的真身 ：每步操作压一张牌，Cmd+Z 永远先弹最近那张
- 函数调用靠栈记路 ：弹出栈顶，自动回到上一层暂停的地方
把规模和更新频率一起算进去
实践时可以把「栈的容量是有限的。下面这个函数 自己调用自己 （这叫递归），左边是代码，右边是调用栈。先 不勾 终止条件跑一次，看看会发生什么；再 勾上 跑一次对比」当作边界提醒：先写下数据量、最常用的操作和允许的延迟，再看 AI 给出的结构是否真的匹配。
从「先玩 · 撤销键的真身」走到「程序怎么记得「回到哪」」
「先玩 · 撤销键的真身」先把问题落在「左边是个迷你文档，用四个按钮随便折腾它。 留意右边 ：你的每一步操作都被压成一张牌，叠在「操作栈」上—— 后做的压在上面 。折腾够了，连按几下「Cmd+Z 撤销」，看看它撤的顺序」上；到了「程序怎么记得「回到哪」」，讨论继续推进到「你让 AI「做晚饭」，它做到一半要切菜，切菜切到一半刀钝了要磨刀……每次「暂停手头的事去干别的」，程序都会把当前进度压进一个栈里。 看下面的动画 （滚到这里会自动播一遍），留意每个任务完成后，程序是怎么 自动 找回上一个任务的」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
遇到一个新的数据结构时，不要从定义开始背。先写出最频繁的操作，再估计数据量和更新方式，最后检查结构是否让这三个条件同时成立。
- 「先玩 · 撤销键的真身」：左边是个迷你文档，用四个按钮随便折腾它。 留意右边 ：你的每一步操作都被压成一张牌，叠在「操作栈」上—— 后做的压在上面 。折腾够了，连按几下「Cmd+Z 撤销」，看看它撤的顺序
- 「程序怎么记得「回到哪」」：你让 AI「做晚饭」，它做到一半要切菜，切菜切到一半刀钝了要磨刀……每次「暂停手头的事去干别的」，程序都会把当前进度压进一个栈里。 看下面的动画 （滚到这里会自动播一遍），留意每个任务完成后，程序是怎么 自动 找回上一个任务的
- 「最后的要点」：Agent 的保险丝 ：最大步数限制，防的就是任务栈的「无限递归」
最后的「最后的要点」把讨论落到「Agent 的保险丝 ：最大步数限制，防的就是任务栈的「无限递归」」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这一课想和你分享的
- 栈 = 一摞盘子：只从顶端放和拿，后进先出（LIFO）
- 撤销键的真身：每步操作压一张牌，Cmd+Z 永远先弹最近那张
- 函数调用靠栈记路：弹出栈顶，自动回到上一层暂停的地方
- 爆栈 = 只压不弹：没有终止条件的递归把栈堆满，程序当场崩溃
- Agent 的保险丝：最大步数限制，防的就是任务栈的「无限递归」
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。