说实话，在React里折腾“撤销”和“重Zuo”这两个功Neng，绝对Neng称得上是前端开发里的“噩梦级”体验。你有没有过这种经历？本来业务逻辑写得挺顺，突然产品经理跑过来说：“哎，这个编辑器Neng不Neng加个Ctrl+Z？” 听到这话，你的心里是不是咯噔一下？

咱们别藏着掖着，传统的Zuo法太痛苦了。要么你得手动去维护一个巨大的状态栈，每次改动dou存一份快照，内存瞬间爆炸；要么你就得把业务代码改得面目全非，到处dou是 `recordHistory` 或者 `saveSnapshot` 这种调用。这哪里是在写业务，简直是在给代码打补丁。

但今天我想跟你聊点不一样的。Ru果我说其实你根本不需要动那些复杂的业务逻辑，只需要几行代码——甚至Ke以说是“三行代码”——就Neng给React项目加上一套工业级的撤销/重Zuo系统，你信不信？这不是玄学，而是基于工程化设计的一种必然选择。咱们这就来拆解一下这背后的魔法到底是怎么运作的。

在深入正题之前，咱们得先复盘一下为什么老办法这么难用。hen多刚入行的朋友，或者那些急于求成的项目，通常会怎么处理历史记录？没错，Zui直观的想法就是“快照栈”。

这思路听起来没毛病：每次状态变了我就把当前整个State深拷贝一份，扔进数组里。想撤销？那就把上一个数组里的状态拿出来覆盖掉现在的。简单粗暴，确实Neng跑。

但是兄弟，真实世界的业务可不是只有几行数据的Demo。一旦你的项目稍微复杂一点，比如是个在线文档编辑器，或者是个复杂的表单设计器，快照方案的弊端立马就会暴露无遗。

就是内存占用。你每次存的dou是全量数据，哪怕只是改了一个标点符号，你也得把整个几兆的对象存一遍。这就像是你为了修一张照片，每次改动dou要把整张相册重新备份一次硬盘不炸才怪。

geng可怕的是业务逻辑的污染。为了存快照，你不得不在业务代码里到处插眼。写个 `addTodo` 吧，得记得存快照；写个 `toggleTodo` 吧，又得记得存快照。一旦哪天脑子短路，漏存了一次Undo功Neng就断了；或者存错了时机，Undo出来个半成品状态，用户直接找客服投诉。这种把“历史记录”强塞进“业务逻辑”的Zuo法，简直就是代码腐坏的催化剂。

既然快照这么重，那有没有轻量级的方案？当然有。这就是Zenith的 `withHistory` 中间件所采用的核心策略——基于 Immer Patches。

这玩意儿其实不难理解。与其记录“整个状态变成了什么样”，不如记录“状态改变了什么”。这就好比录像带和剧本的区别。快照是每一帧画面dou存下来而Patches则是只记录“在第3分钟，主角把帽子摘了”。

Immer 本身就非常擅长处理这种不可变数据的geng新，而 Zenith 的 `withHistory` 则是站在巨人的肩膀上，把 Immer 产生的这些“变geng记录”自动收集起来。这样一来你的历史栈里存的dou是轻量级的补丁包，内存占用极低，而且回放速度极快。这才是现代前端工程该有的样子。

好了铺垫了这么多，咱们来kankan这所谓的“三行代码”到底长啥样。为了让你kan得geng明白，咱们还是拿那个经典的 Todo List 举例。

假设你Yi经有一个基于 Zenith 的 Store 了里面有一堆业务方法，比如 `addTodo`、`deleteTodo` 之类的。这时候，你想加撤销重Zuo，你需要Zuo什么？

你不需要去改 `addTodo`，也不需要去碰 `deleteTodo`。你只需要在 Store 的构造函数里稍微动点手脚。

import { ZenithStore } from "@do-md/zenith";
import { withHistory } from "@do-md/zenith/middleware";
type State = {
  todos: { id: number; text: string; completed: boolean };
  // ui: { ... } // 建议把 UI state 单独分层，并默认不记录进 history
};
class TodoStore extends ZenithStore {
  undo!:  => void;
  redo!:  => void;
  constructor {
    super;
    // 核心魔法就在这三行
    const history = withHistory(this, {
      maxLength: 50, // Zui多记录50步
      debounceTime: 500, // 防抖时间，防止频繁操作
    });
    this.undo = history.undo;
    this.redo = history.redo;
  }
  addTodo {
    this.produce => {
      state.todos.push, text, completed: false });
    });
  }
}

kan到了吗？这就是全部的改动。你引入了 `withHistory`，把它套在你的 Store 实例上，然后把生成的 `undo` 和 `redo` 方法挂载到实例上。就这么简单，你的 TodoList 瞬间就有了时光倒流的Neng力。

这时候你再去调用 `addTodo`，Zenith 会自动在后台帮你把这次操作产生的 Patch 记录下来。你完全不需要告诉它“我要开始记录了”，它就像个贴身秘书，默默地把一切douZuo好了。

这里我想特别强调一下 Zenith 的设计哲学，因为它真的太懂开发者了。hen多其他的库，采用的是 Opt-in的策略，也就是说默认不记录，你得显式地告诉它“这段要记录”。这就像是你默认没有记忆，只有当你刻意按下“记忆”按钮时才Neng记住刚才发生的事。这在实际开发中简直是反人类的。

而 `withHistory` 反其道而行之，它采用的是 Opt-out 的设计。

什么意思呢？它的默认逻辑是：“只要状态变了我就默认这是用户的重要操作，必须记下来。” 这太符合直觉了！用户在编辑器里打字、在画布里拖拽元素，这些当然dou需要撤销。所以你的业务代码 `addTodo`、`toggleTodo`、`deleteTodo`，在接入前后一行dou没改，但它们自动就拥有了历史记录Neng力。

那什么时候需要 Opt-out 呢？典型场景就是 UI State。

比如说你有一个侧边栏开关，或者一个模态框的弹出状态。用户打开侧边栏，然后关掉，这时候他按 Ctrl+Z，是希望“撤销关闭侧边栏”让侧边栏重新打开吗？绝大多数情况下是不希望的。UI 状态通常是瞬态的，不应该进入历史栈，否则你的 Undo 栈里全是这种无关痛痒的噪音，真正想撤销业务操作时得按几十次才Neng找到。

这时候，你只需要在 `produce` 的时候加个配置就行：

this.produce(
   => {
    // state.ui.open = true
  },
  { disableRecord: true } // 告诉 history：这事儿别记，这是咱俩的小秘密
);

这种设计把“历史记录是基础设施”这个理念贯彻得非常彻底。业务逻辑默认享受基础设施的红利，只有在极少数特殊情况下才需要显式地绕过它。

咱们回过头来再kankan那个 `TodoStore`。你会发现，`addTodo` 方法里只有纯粹的逻辑：往数组里塞一个对象。它不知道什么是 Undo，什么是 Redo，也不关心自己是不是被记录了。

这带来一个巨大的好处：你Ke以先写完所有业务逻辑，Zui后再决定要不要接入 Undo/Redo。

hen多团队在开发初期，根本顾不上考虑撤销重Zuo这种高级功Neng。等到项目中期，老板突然提需求了Ru果是用那种侵入性强的方案，这时候你就得哭丧着脸去重构所有业务代码。但用 Zenith 这种方案，你只需要去 Store 的构造函数里加那三行代码，然后把 `undo`/`redo` 按钮绑到界面上。完事儿！不需要重新测试业务流程，因为业务层根本不知道 history 的存在它该咋跑还咋跑。

这就是工程化设计的魅力所在。它把“该记的记，不该记的别记；该合并的合并，不Neng合并的别合并”这些复杂的规则，dou封装在了中间件里留给开发者的只有清爽的接口。

你可Neng会问：“那Ru果用户疯狂输入，每输入一个字母就产生一个 Patch，这历史栈岂不是也会爆炸？”

好问题。这就是为什么我在上面的代码里配置了 `debounceTime: 500`。

在真实的编辑器场景里Undo/Redo 不仅仅是简单的回退，还涉及到“合并”。比如用户在输入框里连续打字，这应该被视为“一个操作”，而不是“一千个操作”。Zenith 的 `withHistory` 内置了这种智Neng合并机制。它会自动把短时间内连续的 Patch 合并成一步历史记录。

当你按下 Ctrl+Z 时它是一次性回退一整段文字，而不是让你按个几百下只为了回退一个单词。这种细节上的打磨，才是区分“玩具代码”和“生产环境代码”的关键。

Ru果你的产品形态就是“编辑器”、“画布”或者“复杂交互表单”，那么 Undo/Redo 对你来说绝对不是锦上添花的功Neng，而是像水电煤一样的基础设施。你Ke以自己造轮子，去研究怎么管理栈，怎么处理指针，怎么优化内存，但说实话，这坑太深了。

geng务实的Zuo法是直接复用成熟的 patch-based history 方案。Zenith 的 `withHistory` 只是其中的一个实现，但它代表了一种先进的方向：把状态管理的复杂度交给库，把业务逻辑的纯粹性留给开发者。

下次当产品经理再问你“这个Neng不Neng加个撤销”的时候，别再皱眉头了。打开你的 Store，敲那三行代码，然后微笑着告诉他：“早就准备好了你要试试吗？”

毕竟咱们写代码是为了解决问题，不是为了给自己制造geng多的麻烦，对吧？