Proxy劫持实现撤销重做详解

本文深入剖析了如何借助 Proxy 实现健壮的撤销重做功能，指出 Proxy 本身仅拦截操作而不保存状态，因此必须配合操作历史栈、路径追踪、深度比较与安全还原机制才能真正落地；文章不仅揭示了直接代理普通对象却无法撤销的根本原因，还系统讲解了嵌套变更捕获、数组递归代理、历史合并优化、撤销/重做时的父级补全与引用一致性等关键难点，并明确划出 Proxy 的能力边界——如 defineProperty、原生数组方法调用、函数内联修改等天然不可撤销的操作，强调技术实现之外更需通过冻结、方法重写和规范约束，让业务代码严格走代理路径，这才是 undo/redo 可靠运行的真正基石。

为什么不能直接 Proxy 一个普通对象就支持撤销

因为 Proxy 本身不记录历史，它只拦截操作、不保存快照。你拦住了 set，但没存上一次的值；拦住了 deleteProperty，但没记被删的是什么。光有拦截器，没有状态快照栈，undo() 就是空谈。

常见错误是写个 const state = new Proxy({}, handler) 就以为万事大吉——结果发现改了十次，undo() 按下去毫无反应，或者直接报错 Cannot read property 'pop' of undefined。

• 必须额外维护一个操作历史栈（history: Array<{ type: 'set'|'delete'|'clear', path: string[], value?: any, oldValue?: any }>）
• 每次 set 前得先读当前值并存为 oldValue，否则重做时无法还原上下文
• 嵌套对象修改（如 state.user.profile.name = 'x'）需路径解析，不能只靠 key 字符串
• 避免对同一属性连续 set 多次却压入多条记录——应合并或节流，否则栈爆炸

如何用 Proxy 拦截并结构化记录每一次变更

核心不是“代理整个对象”，而是“代理每一层访问”，配合路径追踪 + WeakMap 缓存 + 可逆操作建模。重点在 set 和 deleteProperty 两个 trap：

• set(target, key, value, receiver)：先用 Reflect.get(target, key) 拿旧值；若新旧值深度不等（!deepEqual(oldValue, value)），才推入 history；注意处理 undefined 与 NaN 的比较陷阱
• deleteProperty(target, key)：必须同步记录 oldValue，且要区分是真删除（Reflect.deleteProperty 成功）还是静默失败
• 对数组索引赋值（arr[0] = x）和 push 等方法，需在 get 中对返回的数组再递归代理，否则变更不被捕获
• 所有写操作必须走 Reflect.set 或 Reflect.deleteProperty，不能绕过代理直接改 target，否则 history 断链

示例关键片段：

const history = [];
const proxy = new Proxy(state, {
  set(target, key, value, receiver) {
    const oldValue = Reflect.get(target, key);
    const changed = !deepEqual(oldValue, value);
    if (changed) {
      history.push({ type: 'set', path: [key], value, oldValue });
    }
    return Reflect.set(target, key, value, receiver);
  },
  deleteProperty(target, key) {
    const oldValue = Reflect.get(target, key);
    history.push({ type: 'delete', path: [key], oldValue });
    return Reflect.deleteProperty(target, key);
  }
});

撤销/重做时如何安全还原嵌套状态

单纯按顺序 pop history 并 Reflect.set 旧值，会在嵌套对象上出问题：比如 state.a.b.c = 1 被撤销，但 state.a.b 已被后续操作删掉，直接 set(state.a, 'b', oldB) 会失败或污染。

• 还原前先用路径逐级检查父级是否存在，缺失则用 Object.assign 补全空对象（但不触发新 history）
• 对 delete 操作的重做（redo），本质是 set 回原值；对 set 的重做，则是再次 set 当前值（幂等）
• 用 WeakMap 缓存已代理的子对象，避免重复代理导致 identity 不一致（比如两次 proxy.a 返回不同引用）
• 禁止用户直接修改 history 数组，应暴露 undo() / redo() 方法封装逻辑，内部用 history.pop() + 路径 walk + 安全赋值

哪些操作天然不支持撤销，必须提前拦截或降级处理

不是所有 JS 操作都能被 Proxy 拦截，更不是所有都能无损还原。以下行为一旦发生，就不可逆：

• Object.defineProperty(target, key, { writable: false }) —— Proxy 拦不到，且后续 set 会静默失败
• 直接调用 Array.prototype.push.call(proxy, x) —— 绕过 set，history 不记录
• 函数内联修改（proxy.items.forEach(i => i.done = true)）—— 每次 i.done = true 是对原始对象操作，非代理对象
• JSON.parse(JSON.stringify(proxy)) 后再赋值 —— 彻底脱离代理链

应对方式不是硬扛，而是：在初始化时冻结关键元数据（Object.freeze(proxy) 防误写）、重写常用数组方法（push/pop 等挂到代理对象上）、文档明确标注“仅支持点号/中括号赋值”。

真正难的从来不是怎么写 undo，而是怎么让业务代码老老实实走你的代理路径——这点比任何技术细节都关键。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~