Proxy 实现响应式核心是通过 get/set 拦截建立依赖关系：get 中用 track() 收集当前 active effect 到 WeakMap 管理的依赖集，set 中用 trigger() 触发对应 key 的所有副作用；需递归代理、特殊处理数组、配合 effect 包装函数自动注册与清理依赖。
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] 的函数。
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
- 不用
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 可能触发多个副作用，其中某个失败不该阻塞其余更新，但也不该让失败副作用的依赖残留——这需要每个副作用执行前后都做独立的依赖快照与还原。
