本文深入剖析了 Proxy 如何作为现代响应式系统的核心引擎，通过精巧的 get/set 拦截、WeakMap 依赖映射、副作用栈管理与 effect 自动注册机制，实现数据变更到 UI 渲染的零手动绑定自动同步；同时直击真实工程中的痛点——从数组方法拦截、嵌套代理、内存泄漏防范，到 SSR 兼容、异步收集限制与原子性更新保障，层层拆解那些看似优雅却极易踩坑的关键细节，帮你真正理解 Vue3、Pinia 等框架响应式背后的硬核逻辑。

Proxy 怎么拦截 get/set 实现响应式追踪

核心在于用 Proxy 包裹原始数据对象，重写 get 和 set 拦截器：在 get 中记录当前正在执行的副作用函数（如 UI 渲染函数），在 set 中触发所有依赖该属性的函数重新执行。

关键点不是“能劫持”，而是“如何建立依赖关系”。get 拦截时需主动调用一个全局依赖收集函数（比如 track()），把当前活跃的副作用与被读取的 key 关联起来；set 拦截时再通过 trigger() 找出所有关联的副作用并执行。

• 必须用栈管理“当前活跃副作用”，否则嵌套调用会污染依赖关系
• 不能直接代理原始对象，要递归代理嵌套对象和数组——否则 obj.list[0].name 的深层访问不会被拦截
• 数组索引赋值（arr[0] = x）、length 变更、push/pop 等方法需单独处理，原生 Proxy 不自动拦截这些

为什么不能只靠 Proxy，还得配合 WeakMap 做依赖映射

Proxy 本身不保存状态，每次 get 都是无记忆的。要让 obj.name 的变化能通知到所有读过它的 UI 函数，就得有个外部结构来存“谁依赖了谁”。WeakMap 是唯一合理选择：键是被代理的对象（避免内存泄漏），值是该对象所有 key 对应的依赖集合（通常用 Set 存副作用函数）。

典型结构：targetToDepMap.get(target)?.get(key) → 返回一个 Set，里面是所有订阅了 target[key] 的函数。

• 不用 Map：防止代理对象无法被 GC，造成内存泄漏
• 每个 key 都要独立维护依赖集：改 obj.a 不该触发读过 obj.b 的函数
• 嵌套对象代理后，父对象和子对象各自有独立的 WeakMap 条目，形成依赖链

UI 渲染函数怎么自动注册为副作用并响应更新

不能指望开发者手动写 watch(() => render())。真正的自动化，是让 render() 在首次执行时，自动进入“依赖收集模式”：此时所有被读取的响应式属性都会把当前 render 函数记入自己的依赖集。

实现上，render() 需被包装进一个 effect(fn) 函数中执行。该函数会：

• 将 fn 推入依赖收集栈
• 立即执行 fn
• 执行完后从栈中弹出，并清理临时状态

后续任何 set 触发时，就遍历对应 key 的依赖 Set，逐个执行其中的 render 函数。

• 必须禁止重复加入同一副作用：否则多次渲染会无限循环
• 执行副作用前要暂停依赖收集，避免 render 内部读取新属性导致误收集
• 如果 render() 里有异步逻辑（如 setTimeout），那里面的读取不会被收集——这是设计限制，不是 bug

真实项目中容易忽略的边界问题

这套机制在 demo 里跑得飞快，一到实际 UI 场景就暴露问题：组件销毁后残留的副作用没清理，导致内存泄漏或更新空节点；深层嵌套对象代理性能差；for...in 或 Object.keys() 无法触发依赖收集（因为没走 get）；服务端渲染时 Proxy 不可用。

• 组件卸载时，必须调用 stop(effect) 显式清除所有依赖记录
• 对大数组或频繁更新的对象，考虑加防抖或批量更新（queueMicrotask 合并触发）
• 需要补充 ownKeys 和 has 拦截器，才能支持 in 操作符和 Object.getOwnPropertyNames
• SSR 场景下，要么 fallback 到 Object.defineProperty（仅支持已知属性），要么延迟初始化 Proxy

最常被跳过的一步：没有做“依赖清理”的原子性保证。一次 set 可能触发多个副作用，其中某个失败不该阻塞其余更新，但也不该让失败副作用的依赖残留——这需要每个副作用执行前后都做独立的依赖快照与还原。

到这里，我们也就讲完了《Proxy 劫持属性，实现数据驱动 UI 自动更新》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！