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