Vue 响应式页面出现内存增长先核对数据和副作用的边界复杂表单、流式结果和推荐建议放进同一个 Vue 页面后内存曲线偶尔会上扬并不罕见。但“用了响应式对象所以泄漏了”并不是结论。先通过堆快照、组件销毁后的对象引用和网络连接状态确认现场才能知道是数据本来就保留得多还是已经离开的页面仍被某个副作用引用。排查这类问题时最值得先看的有两处大对象是否被做成了深度响应式数据订阅、watch 和连接是否随组件生命周期停止。它们处理的是不同问题混在一起改往往会让页面更新变得不可预测。原始大数据不一定需要被深度追踪模型返回的长文本、检索结果、树形结构或图数据未必每一个深层字段都会直接驱动界面。若把它们整体放进 reactive 或普通 refVue 会在访问路径上建立依赖关系。对于频繁替换、结构很深的数据这可能带来额外的代理和调度开销。先问一个简单的问题页面究竟依赖它的哪一部分如果只关心“当前结果是否已到”和“展示哪一条摘要”可以将完整原始载荷保留为普通对象或浅层引用只让少量展示字段参与更新。使用 shallowRef、markRaw 等 API 时也要保证团队能理解边界深层字段变化不会自动刷新视图更新它们时需要显式替换外层值或维护一个明确的版本状态。不要为了省一点代理成本把所有对象都标为原始值。表单字段、加载状态和真正会被模板读取的业务状态仍然应该保持响应式。选择浅层还是深层应由读写方式决定而不是由“数据来自 AI”决定。副作用必须跟着组件结束内存问题更常见的来源是生命周期遗漏。页面创建了 watch、定时器、事件监听、SSE 或 WebSocket离开路由后却仍在运行它们继续持有组件闭包和数据引用垃圾回收自然无法释放。组合式函数里创建副作用时要明确它运行在哪个 effect scope 中。由组件 setup 创建的 watcher 通常会随组件卸载停止如果副作用来自独立 scope、全局 store 或异步回调则需要保存停止函数并在不再需要时调用。网络连接和定时器同样如此不能只依赖“页面应该已经没了”。尤其要留意异步初始化。请求完成时组件可能已经卸载回调若继续写状态既可能出现警告也可能重新建立订阅。可以在发起请求时绑定取消信号或在回调中检查当前实例是否仍然有效。这样处理比在每个 catch 中吞掉错误更容易维护。SSR 和浏览器逻辑要分开初始化服务端渲染环境没有 window、document 和浏览器连接。任何依赖这些对象的逻辑都应只在客户端生命周期中执行。把连接创建写在模块顶层或服务端可执行的 setup 路径中容易导致服务端渲染时出现意外副作用也会让多次请求之间共享不应共享的状态。配置也不应混用。公开给浏览器的配置与服务端凭据是两回事浏览器端不该持有服务端密钥。若某个模型或数据服务需要凭据应由受控后端代理请求并由前端只传递必要参数。内存排查时顺便检查这一点能避免把环境问题误判为框架问题。用可复现的步骤验证先选一个能稳定重现的交互进入页面、执行若干次查询、切换路由、等待一段时间再回到页面。记录堆快照前后仍存活的组件实例、ReactiveEffect、监听器和网络连接。对象数量增长本身没有意义关键是它为何还被引用。然后一次只改一类边界。比如先停止遗留连接再观察销毁后的引用链确认无误后再试着将一个大载荷改成浅层引用。每次改动都检查功能是否仍正确更新尤其是嵌套字段和错误状态。Vue 的响应式系统不会替应用决定数据应该活多久。让数据的响应范围、连接的存活范围和页面生命周期对齐内存问题才会从偶发的监控曲线变成可以验证、可以修复的工程问题。