响应式状态深度监听的关键是避免无效监听、控制更新粒度、确保变化可追溯；Vue 3 默认深层响应，但需通过computed+toRaw、shallowRef+triggerRef、watch合理配置及结构化Store设计来实现精准响应。

响应式状态的深度监听，关键不在“监听得多深”，而在于避免无效监听、控制更新粒度、确保变化可追溯。Vue 3 的 reactive 和 ref 默认已是深层响应式，但“自动响应”不等于“合理响应”——真正需要关注的是：哪些嵌套字段该触发视图更新？哪些变化应合并或忽略？哪些操作必须强制触发？

用 computed + toRaw 控制监听边界

当 Store 中某个复杂对象（如 user.profile.address）只在特定场景下才需响应，直接监听整个对象会导致过度更新。此时应剥离无关层级：

• 用 toRaw() 获取原始对象，避免代理干扰逻辑判断
• 用 computed 封装具体字段路径，例如：
  const city = computed(() => toRaw(store.user).profile?.address?.city)
• 组件中仅依赖 city，而非 store.user 整体，更新更精准

对高频嵌套变更使用 shallowRef + triggerRef

如果对象内部频繁修改（如实时编辑的富文本内容、拖拽中的坐标数组），每次深层 setter 都会触发依赖收集与更新，性能易受损。推荐策略：

• 将深层可变结构用 shallowRef 包裹（仅顶层响应）
• 手动调用 triggerRef() 显式通知更新，例如在保存/确认/节流后
• 配合 watch 监听关键字段（如 isEditing 或 version），代替监听整个嵌套树

用 watch + deep: true 的正确姿势

确实需要深度监听时，watch 的 deep: true 不是万能开关，它有明确适用边界：

• 仅用于调试、日志、同步副作用（如向外部 SDK 推送变更），不要用于触发视图更新
• 务必搭配 immediate: false 和防抖（lodash.debounce 或自定义节流）
• 监听前先用 isProxy 和 toRaw 判断是否为响应式对象，避免重复包装或死循环

结构化 Store：把“深度”变成“分层契约”

最可持续的方式，是让 Store 自身拒绝“任意深度变更”。建议在设计阶段就约定：

• 每个模块暴露明确的原子更新方法（如 updateUserEmail()、setAddressCity()），内部统一处理响应式逻辑
• 禁止直接赋值深层属性（store.user.profile.address.city = 'Shanghai'），改用方法调用
• 在更新方法内，用 nextTick 或 queuePostFlushCb 统一聚合多次变更，减少渲染次数