Proxy拦截状态变更，实现数据层撤销重做功能

本文深入探讨了如何基于 Proxy 构建真正可靠的前端数据层撤销重做功能，直击“仅拦截 set”方案的三大致命缺陷：无法捕获数组方法调用、遗漏未代理嵌套对象的深层修改、以及破坏多属性变更的事务原子性；进而提出以“操作日志 + 显式事务标记 + 按需代理 + 轻量快照”为核心的工程化方案——通过统一 commit 入口封装可逆操作、在 get 陷阱中动态代理嵌套结构、重写数组原型方法实现语义化变更捕获，并巧妙分离真实状态与 UI 草稿，确保撤销不丢失用户输入、回滚不引发视图错乱，最终在保证功能完备的同时兼顾性能与可维护性。

直接用 Proxy 拦截 set 就能记录变更，但只拦 set 不行——撤销重做需要完整操作快照、可逆执行、状态回滚能力，必须配合历史栈 + 变更描述 + 状态克隆机制。

为什么只代理 set 无法支持可靠撤销

单纯在 set 陷阱里 push 一条“旧值→新值”记录，会漏掉三类关键信息：

• 数组索引赋值（如 list[2] = 'x'）或 push/splice 等方法调用，不会触发 set（除非你额外拦截 apply 或重写数组方法）
• 嵌套对象深层修改（如 user.profile.name = 'Bob'），若 profile 未被递归代理，变更根本不会被捕获
• 多个属性连续修改（如 a=1;b=2;c=3）会被拆成多条独立记录，但用户视角是一次“提交动作”，撤销时应原子回退

所以必须把“一次业务操作”显式标记为一个单元，不能依赖底层属性访问自动聚合成事务。

用 Proxy + 操作日志 + 快照实现可撤销数据层

核心是把每次用户触发的业务动作（比如“添加订单项”“更新收货地址”）封装为一个带 execute 和 undo 方法的对象，由 Proxy 在 set 中不直接执行，而是生成该操作并推入历史栈。

实操要点：

• 所有对响应式数据的修改，必须走统一入口函数（如 commit(operation)），禁止直接赋值；operation 是形如 { type: 'UPDATE_FIELD', path: ['user', 'email'], value: 'a@b.com' } 的描述对象
• Proxy 的 set 陷阱仅用于拦截调试/误操作，生产环境应禁用直接赋值，靠 commit 驱动
• 历史栈用两个数组维护：undoStack 存已执行的 operation 对象，redoStack 存刚 undo 过的操作；每个 operation 必须自带 undo 实现（例如还原 path 对应的老值）
• 避免深拷贝性能损耗：用 structuredClone（现代浏览器）或 immer 的 produce 做不可变更新，快照只存 diff 而非全量状态

示例片段（简化版）：

const state = { count: 0, items: [] };
const history = { undoStack: [], redoStack: [] };

function commit(op) {
  const oldState = structuredClone(state);
  // 执行变更（此处用 immer 或手动路径更新）
  applyOperation(state, op);
  history.undoStack.push({ op, oldState });
  history.redoStack = [];
}

// Proxy 仅作防护
const proxied = new Proxy(state, {
  set(target, key, value) {
    console.warn('禁止直接赋值，请使用 commit()');
    return false;
  }
});

嵌套对象和数组的变更如何统一捕获

Proxy 默认不递归代理子对象，而撤销重做要求任何层级的修改都可追溯。解决方案不是无脑递归，而是按需代理 + 路径标记：

• 在 get 陷阱中，当返回值是对象或数组时，检查它是否已被代理；若否，用同一套 handler 创建新 Proxy，并记录该值对应的原始路径（如 ['user', 'profile']）
• 所有数组方法（push, pop, splice）需包装：通过 get 返回的代理数组，其原型方法要被重写，调用前先生成 ARRAY_PUSH 类型操作并 commit
• 关键点：不要在 set 里处理数组索引赋值（arr[0] = x），因为这仍会触发 set，但语义上属于“替换元素”，应转为 ARRAY_SET 操作，含索引与旧值

这意味着你得为数组单独实现一层代理逻辑，handler 里区分 typeof value === 'object' 和 Array.isArray(value)，并分别处理。

撤销时如何保证视图同步且不丢失未提交变更

撤销不是简单 Object.assign 回老状态——那会丢掉当前用户正在输入但尚未 commit 的临时内容（比如表单里打了半截的地址）。正确做法是：

• 真实状态（state）始终只由 commit 更新；UI 层读取的是 proxy 包装后的响应式对象，它内部可缓存“草稿值”
• 撤销时，从 undoStack 弹出操作，调用其 undo() 方法反向修改 state，然后触发一次强制刷新（如调用 triggerEffect）
• 如果用户在撤销后又做了新操作，清空 redoStack 并将新操作推入 undoStack —— 这是标准撤销链行为，不能跳过
• 注意：若某次 commit 修改了 5 个字段，但 UI 只渲染了其中 2 个，撤销后那 3 个字段的变更也必须生效，否则状态不一致

最易被忽略的一点：撤销重做功能本身不该成为性能瓶颈。每条操作日志必须轻量（只存路径、类型、必要值），而非整个 state 快照；diff 计算和状态恢复逻辑要可预测、可测试，不能依赖副作用顺序。

到这里，我们也就讲完了《Proxy拦截状态变更，实现数据层撤销重做功能》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！