shallowRef 不直接优化大数据量渲染但能避免对大型对象或数组深度响应式代理减少 Proxy 开销适用于整体替换场景如分页加载不适用于需监听嵌套属性变化的场景。shallowRef 不是用来直接优化大数据量渲染的“银弹”但它在特定场景下能显著减少不必要的响应式开销从而间接提升大数据量列表或表格的渲染性能。关键在于避免对大型普通对象或数组做深度响应式代理。什么时候该用 shallowRef当你有一个很大的普通 JavaScript 对象比如包含成百上千个字段的配置项或超长数组并且你只打算整体替换它而不是频繁修改它的内部属性时shallowRef 就很合适。Vue 的 ref 会对值做 reactive() 处理而 shallowRef 只让 .value 本身是响应式的内部结构保持原样——不递归转响应式。? 适合整个数据集一次性替换如分页加载新列表、搜索后全量更新 ? 不适合需要监听 item.name 变化并触发更新的嵌套响应式场景 ?? 注意v-for 渲染时仍需 keyshallowRef 不解决 key 缺失导致的复用问题对比 ref 和 shallowRef 的实际开销差异假设你有这样一个 10,000 条记录的数组const largeList Array.from({ length: 10000 }, (_, i) ({ id: i, name: item-${i}, desc: ... }))ref(largeList)Vue 会遍历每一项对每个对象执行 reactive()产生上万个 Proxy 实例初始化慢、内存高、GC 压力大 shallowRef(largeList)仅对 largeList 这个数组引用做响应式内部对象仍是普通 JS 对象无 Proxy 开销怎么配合 v-for 安全使用shallowRef 的值变化会触发视图更新但前提是组件要“读取”到这个响应式引用。确保在模板中正确访问? 正确v-foritem in list.value :keyitem.idlist 是 shallowRef ? 更推荐在 setup 中解构为常量 const list shallowRef(data); const items computed(() list.value)模板中直接写 v-foritem in items ? 错误直接 const items list.value 赋值给响应式变量会丢失响应性进阶技巧按需 shallow 局部 reactive如果某些关键字段如 item.isSelected确实需要响应式又不想全量 reactive可以组合使用用 shallowRef 管理整个列表 对需要交互的字段单独抽离为 ref 或用 reactive 包裹局部对象 例如选中状态用 const selectedIds ref(new Set())渲染时靠 selectedIds.value.has(item.id) 判断避免污染原始数据响应性