最近在优化一个数据中台的前端项目几千行的表格数据用ref包了一个大数组结果每次筛选、排序、切换页面都卡得让人怀疑人生。排查来排查去发现瓶颈根本不在 DOM 渲染而在 Vue 3 响应式系统的“深度代理”上。shallowRef就是在这种场景下救命的 API——它只对.value这层做响应式追踪不会递归代理内部对象省掉了一大笔初始化和更新时的开销。这篇文章我想把shallowRef的原理、适用场景、实操手法和踩坑记录都梳理一遍给正在做 Vue 3 性能优化、或者刚接触响应式原理的朋友一份能直接抄作业的参考。1. 为什么说“深层响应式”是性能瓶颈1.1 ref 和 reactive 背后到底做了什么Vue 3 的响应式系统基于 Proxy 实现。当你调用ref()或reactive()时Vue 会对传入的对象做一层递归代理——注意是递归。也就是说哪怕你只是想存一个配置对象只要它嵌套了几层Vue 就会把每一层的每一个属性都包上 Proxy 拦截器。我打个比方reactive像是一个小区物业每栋楼、每个单元、每户人家都装了安保系统。你只是想让住户住进去结果物业把所有门窗都改造了。这个改造过程本身就有成本而且访问任何属性都要经过一层拦截逻辑。Vue 3 官方文档里其实写过ref()在传入对象时内部会调用reactive()做深度转换。所以下面这段代码里data内部的list数组和每一个元素都是被代理过的import { ref } from vue const data ref({ list: [ { id: 1, name: 张三, age: 28 }, { id: 2, name: 李四, age: 32 } ] })这样做的优点是“无脑开发”你不需要关心什么时候嵌套改了、什么时候不触发更新深层响应式帮你兜底。但代价也很明显——数据越复杂、嵌套越深代理对象越多内存占用和访问开销越大。1.2 深层代理的开销到底有多大很多朋友对“开销”没概念。我换个角度说表格里几千条数据每条数据对象有十几个字段用reactive包裹后每一个字段访问都会走 Proxy 的get拦截每一次修改都会触发set拦截并派发更新。虽然单个操作耗时是微秒级但高频操作叠加起来卡顿就非常明显。更扎心的是初始化的开销。我实测过一个场景用reactive包装一个包含 5000 个对象、每个对象 20 个字段的数据源初始化耗时大约 80ms 到 120ms而用shallowRef包装同样的数据初始化几乎瞬间完成耗时可以忽略不计。你可能会问那shallowRef改了内部数据不就没响应了吗这个问题的答案恰恰是它最大的特点也是最大的使用门槛——我们需要在“响应式”和“性能”之间做取舍。很多场景下我们根本不需要对数据的每一个字段做深度响应只需要在整体替换数据时让界面更新一次就够了。这就是shallowRef存在的意义。2. shallowRef 的核心机制先搞懂再动手2.1 shallowRef 的数据追踪逻辑shallowRef的名字已经说明了它的行为浅层 ref。它只对.value这一层属性做响应式追踪。当你执行state.value newData时Vue 能感知到变化并更新相关依赖但如果你直接修改state.value.someKeyVue 完全没有反应。看这个例子import { shallowRef } from vue const state shallowRef({ count: 0, user: { name: 张三 } }) // 这个操作会触发更新 state.value { count: 1, user: { name: 李四 } } // 这个操作不会触发任何更新 state.value.count 2你可以把shallowRef想成一个快递柜快递柜只记录“门有没有被打开过”至于柜子里面的包裹里装了什么、有没有被拆开快递柜一概不管。只有当你把整个柜门换掉整体替换.value时快递柜才会通知收件人。2.2 triggerRef手动拉响更新警报既然内部属性变化不会自动触发更新那如果我们就是想在某些情况下强制刷新怎么办Vue 提供了triggerRefAPI它可以手动触发和shallowRef关联的副作用。import { shallowRef, triggerRef } from vue const state shallowRef({ list: [] }) function addItem(item) { state.value.list.push(item) triggerRef(state) // 手动通知依赖更新 }这里有个重要的细节triggerRef接收的是shallowRef返回的 ref 对象本身而不是.value。我见过有人写triggerRef(state.value)这是完全不生效的因为state.value只是普通对象根本没有触发依赖的能力。triggerRef的存在让shallowRef变得非常灵活你既可以利用浅层响应式跳过深层代理的性能开销又能在需要的时候“按需点炮”手动控制更新时机。这种组合拳在实际项目中非常实用。2.3 shallowRef 和 ref、markRaw 的差异为了讲清楚差异我整理了一个对比表方便你直接看结论特性refshallowRefreactive深层代理是否是内部属性变化触发更新是否是整体替换触发更新是是是强制触发更新不需要triggerRef不需要初始化大型数据开销高极低高适合场景常规数据大对象/整体替换复杂嵌套但需深层响应另外还有一个经常和shallowRef一起出现的 APImarkRaw。markRaw的作用是标记一个对象让它永远不会被 Proxy 代理。我之前把 ECharts 实例、Mapbox 实例、第三方 SDK 对象用reactive包过结果每次访问内部方法都多一层 Proxy 开销有时候还会因为 Proxy 代理导致第三方库内部this指向出错。后来改用markRaw标记这些实例再塞进shallowRef的.value里既保留了对实例的引用又避免了代理带来的各种问题。这两个 API 搭配使用是处理第三方库和大型实例的经典方案。3. 哪些场景最适合用 shallowRef 做性能优化3.1 场景一大型表格数据与整体替换这是shallowRef最核心的使用场景。后台管理系统里表格数据往往是查一次、换一整套。用户点击搜索、翻页、刷新本质上都是简单的“旧数据整体替换成新数据”。这种情况下我们根本不需要深层响应式——反正数据是整体换掉的内部字段怎么变不重要。我之前优化过一个采购订单列表原来用ref包裹整个数据源初始化时明显感觉页面loading时间变长。换成shallowRef后初始化耗时从大约 100ms 降到了接近 0ms。关键代码就一行import { shallowRef } from vue const tableData shallowRef([]) async function fetchData(params) { const res await api.getOrders(params) tableData.value res.data.list // 整体替换触发更新 }模板里v-for遍历tableData完全不受影响因为渲染依赖的是.value这一层。升级过程中我没有改任何模板代码只改了ref到shallowRef这一个地方性能提升立竿见影。3.2 场景二第三方地图、图表实例与 markRaw做数据可视化的时候ECharts、Mapbox、Leaflet 这些库经常需要和 Vue 组件打交道。这些实例对象结构复杂、内部方法多、还带着 DOM 引用如果直接塞进reactive或者ref很容易出现两个问题一是 Proxy 代理大量内部属性带来的额外开销二是某些库内部方法依赖this的正确指向被代理后可能出现奇怪的报错。我当时用markRaw配合shallowRef解决了这个问题import { shallowRef, markRaw } from vue const chartInstance shallowRef(null) function initChart(el) { const chart markRaw(ECharts.init(el)) chartInstance.value chart } function updateChart(option) { chartInstance.value.setOption(option) }这里markRaw告诉 Vue“这个对象别给我做代理直接保存原始引用”而shallowRef则确保我们只追踪实例的替换不追踪实例内部的方法和属性。实测下来频繁调用setOption时性能明显提升而且再也没有遇到过第三方库内部this被 Proxy 劫持导致的问题。3.3 场景三不可变数据流与函数式更新如果你在用 Immer、Immutable.js 这类库管理数据或者习惯用不可变数据的方式开发shallowRef也是天作之合。不可变数据流的核心理念就是每次修改都产生一个全新的数据结构旧数据保持不变。既然数据每次都整体换新那响应式系统只需要感知到“引用变化”就够了。import { shallowRef } from vue import produce from immer const state shallowRef({ todos: [], filter: all }) function addTodo(text) { state.value produce(state.value, draft { draft.todos.push({ id: Date.now(), text }) }) }produce返回的是一个全新的对象state.value ...整体替换正好落在shallowRef的响应式范围内。这样既享受了 Immer 带来的不可变数据优势又避免了深层响应式代理对 Immmer 内部结构的无意义“包装”。4. 实操案例我把一个卡顿页面优化到了丝般顺滑4.1 一个完整的优化过程记录为了让你有更完整的参考我复盘一个最近做过的优化案例。这个页面是一个“销售明细报表”功能包括查询订单、按时间筛选、按状态筛选、导出数据。列表最多的时候一次性渲染 8000 行每行 18 个字段。优化前的代码节选import { ref, computed } from vue const rawData ref([]) const filteredData computed(() { return rawData.value.filter(item item.status filter.value) })问题表现在初始化页面时rawData赋值后页面白屏接近 1 秒点击筛选按钮后UI 冻结约 400ms。我用浏览器的 Performance 面板录制了一份 Profile发现耗时大头根本不在筛选逻辑和 DOM 渲染而是在 Vue 初始化响应式代理的阶段——ref([])传入 8000 个对象时Vue 会递归代理这 8000 个对象以及它们的所有属性这个操作非常吃 CPU。优化后的代码import { shallowRef, computed, triggerRef } from vue const rawData shallowRef([]) const filter shallowRef(all) const filteredData computed(() { return rawData.value.filter(item item.status filter.value) }) function applyFilter(newFilter) { filter.value newFilter // rawData 内部数据没有变化时computed 依赖的 rawData.value 引用没变 // 但 filter.value 变化了所以 computed 会重新计算 } function loadData(data) { rawData.value data // 整体替换触发更新 }初始化耗时从 100ms 左右降到几乎不可感知页面白屏消失。筛选操作本身因为filter是shallowReffilter.value变化能触发 computed 重新计算完全没受影响。整体用户体验从“卡得不想用”变成了“秒开、筛选几乎无感”。4.2 优化前后的性能对比数据我用 Chrome DevTools 的 Performance 面板记录了优化前后的关键指标指标优化前ref优化后shallowRef初始化代理耗时~100ms~2ms页面首次渲染总耗时~900ms~350ms筛选操作响应时间~400ms~80ms内存占用粗略明显偏高降低约30%注意这些数据在不同的设备上会有差异但趋势非常一致对象数量越大、嵌套越深shallowRef的优势越明显。4.3 还有一个容易被忽略的组合技巧我在实际项目里发现shallowRef搭配computed有奇效。computed内部读取shallowRef.value时会自动建立依赖关系。所以你可以这样设计const state shallowRef({ list: [], keyword: }) const visibleList computed(() { const data state.value const kw data.keyword return data.list.filter(item item.name.includes(kw)) })只要你在业务代码里保证搜索关键词变化时通过整体替换state.value来更新数据那么computed就能准确感知到数据变化。这个模式比在shallowRef内部单独存一个keyword字段更清晰——所有数据都存在一个整体对象里替换时一起更新computed依赖只需要追踪.value引用变化即可。5. 常见问题与排查技巧实录5.1 内部属性改了界面怎么不动了这是shallowRef踩坑排行榜第一名。很多朋友从ref切换到shallowRef后发现直接改内部对象属性页面纹丝不动。排查思路确认你是不是直接改了.value内部的属性比如state.value.list.push(item)。这不会触发更新。解决办法是整体替换state.value { ...state.value, list: newList }或者调triggerRef(state)手动触发。经验之谈如果你的代码逻辑里存在大量“原地修改内部属性”的操作shallowRef可能不适合你不如继续用ref。shallowRef是给那些“以整体替换为核心”的业务场景准备的。5.2 用 triggerRef 却没有任何效果triggerRef不生效最常见的原因是参数传错了。记住你要传的是shallowRef返回值不是.value。另外还有一种情况你已经有其他依赖发生了变化导致triggerRef的更新看起来没效果其实只是重复触发。排查方法先用console.log打印你的 ref 对象看看传入的东西长什么样。state应该打印出一个 Ref 对象而不是普通对象。如果通过了这一步还是不生效检查你更新的时机是不是在异步流程里比如 setTimeout 或者 promise 回调里确保是在组件挂载完成后的正确生命周期内调用的。5.3 结构赋值把响应式整没了有个很容易被忽视的坑从shallowRef解构出来数据再用解构出来的变量去修改。const state shallowRef({ count: 0 }) // 错误示范 const { count } state.value count // 完全无效count 是普通变量 // 正确示范 state.value { ...state.value, count: state.value.count 1 }很多初学shallowRef的朋友会下意识地解构.value然后就懵了。记住一个原则shallowRef的数据访问和更新永远通过.value这个入口。不要试图把内部属性解构出来当成响应式变量用。5.4 什么时候坚决不能用 shallowRef再好的工具也有它的边界。如果遇到下面的场景建议老老实实继续用ref或reactive表单数据表单的每一个输入框都需要双向绑定内部属性必须深层响应。复杂状态交互多个组件共享同一个状态且各个组件都在深度修改内部字段。数据增量更新频繁比如列表里只改了某一条的某个字段其他都不变。如果整个列表用shallowRef每次都要把整个列表重新赋值反而可能带来性能问题。我见过有些团队为了追求“性能优化”强行把ref全部换成shallowRef结果一大堆 bug最后又退回ref。shallowRef不是银弹它的核心价值是“跳过不需要的响应式代理”前提是你得自己确定哪些数据真的不需要深层响应。5.5 和 TypesScript 相处的一些小细节如果你在用 TypeScriptshallowRef的泛型推断有时候会给你“意外惊喜”。比如const state shallowRef({ list: [] }) state.value.list.push(1) // TS 不会报错但运行时不会触发更新这里 TS 的静态检查不会提醒你在修改内部数组因为类型上state.value确实是包含list的对象。要避免这个问题可以在定义时就声明清楚泛型并且约定好只能通过替换整个value来更新数据type ListState { list: number[] } const state shallowRefListState({ list: [] })本质上还是开发规范的问题。我会在项目里给shallowRef的赋值操作封装一个便捷方法确保所有数据更新都走同一个入口而不是到处直接改.value内部属性function setList(newList: number[]) { state.value { ...state.value, list: newList } }这样既保证了类型安全也统一了更新路径团队协作时不会出现“谁也不知道这里为什么没有触发更新”的尴尬局面。最后再分享一个小技巧我在处理一个地图项目时发现shallowRef和nextTick搭配起来做复杂交互非常顺手。地图的图层数据经常是后端推送一整个新数据集我用shallowRef存储数据集然后整体替换再配合nextTick在地图 DOM 更新后执行渲染逻辑。替换数据的性能开销几乎为零而且因为只追踪引用变化地图渲染的时机控制得非常精确。如果你正在为大数据量的页面卡顿发愁先别急着上虚拟滚动或者分页加载这些“重型武器”用shallowRef在数据源这一层做一次优化很可能就解决问题了。我个人的体会是性能优化不是把所有工具都堆上去而是先找到最消耗性能的那一环用最轻量、最精准的方式去突破。shallowRef就是这样一个值得放进你工具箱的轻量利器但它只属于那些清楚知道“自己需要什么”的开发者。