watcheffect 优化核心是“收窄”而非“加深”：严格限制响应式属性访问路径、用 computed 缓存中间计算、避免动态依赖抖动、按职责拆分多个 watcheffect，从而降低追踪粒度与重执行开销。
watchEffect 本身不支持 deep 配置，它只自动追踪当前执行中**实际访问到的响应式属性**。所以“深度嵌套优化”不是给 watchEffect 加 deep，而是通过控制访问路径、减少无效依赖、拆分关注点来规避性能开销。
只访问真正需要的字段
大型嵌套对象（如 user.profile.address.city）若在 watchEffect 中直接展开整个对象或遍历深层结构，会触发大量 getter，导致依赖收集膨胀、重执行变慢。应严格限制访问范围：
- 用计算属性提前提取关键路径，再在 watchEffect 中只读取该计算值
- 避免在副作用函数里写
JSON.stringify(obj)、Object.keys(obj)或for...in遍历——这些操作会强制触发所有属性的 getter - 若只需监听某几个字段，改用
watch(() => [obj.a, obj.b.c], ...)显式声明，比 watchEffect 更可控
用 computed 缓存中间状态
当嵌套结构需多次计算或格式化时，把逻辑移入 computed，watchEffect 只监听这个计算结果：
- computed 具有缓存性，只要依赖没变，不会重复计算；watchEffect 每次重执行都会重新跑一遍逻辑
- 例如：监听
user.orders.filter(o => o.status === 'pending').length，应封装为const pendingCount = computed(() => user.orders.filter(...).length)，再在 watchEffect 中仅读pendingCount.value - 这样既降低响应式追踪粒度，又避免每次重执行都做全量过滤
避免动态依赖抖动
watchEffect 的依赖集合会在每次执行后重置并重新收集。如果副作用函数内存在条件分支（如 if (type === 'A') useX() else useY()），且 type 频繁切换，会导致依赖反复增删，引发不必要的重执行：
- 对高频变动的控制变量（如筛选类型、视图模式）单独用 watch 处理，保持 watchEffect 内部依赖稳定
- 必要时用
onInvalidate清理上一次未完成的异步操作（如取消 pending 的请求），防止竞态累积 - 大型嵌套数据建议配合
shallowRef或markRaw对非响应式子树做隔离，避免无意义追踪
按需拆分多个 watchEffect
一个 watchEffect 承担太多职责，容易变成“巨无霸副作用”，难以维护也难优化。可依据业务语义拆解：
- 一个负责 UI 状态同步（如更新表单 disabled 状态）
- 一个专注数据导出逻辑（如生成 CSV 字段映射）
- 一个处理远程同步（如防抖提交变更）
- 每个 watchEffect 关注更小的数据切片，依赖更少，触发更精准
本质上，watchEffect 的优化不靠“加深”，而靠“收窄”——收窄访问、收窄计算、收窄依赖、收窄职责。
