只代理 set 无法支持可靠撤销，因为会漏掉数组方法调用、嵌套对象未代理导致的深层修改遗漏、以及多个属性连续修改缺乏事务原子性，必须结合历史栈、变更描述和状态克隆机制。
直接用 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 而非全量状态
示例片段（简化版）：
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
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 计算和状态恢复逻辑要可预测、可测试，不能依赖副作用顺序。
