Vue渲染死循环表现为页面卡死、CPU飙升、组件反复重渲染，根源在于computed/watch中隐式修改依赖数据导致watcher闭环触发；定位需用Chrome Performance面板观察Vue标记密集重复及queueWatcher→flushSchedulerQueue→updateComponent调用栈闭环；修复应切断依赖链、冻结可疑字段、加守卫判断、延迟更新。
死循环的典型表现和快速定位方法
页面卡死、CPU 占用飙升、控制台无报错但组件反复重渲染，往往是 Vue 渲染死循环的信号。最直接的线索是 watcher 触发后又触发自身更新，比如在 computed 或 watch 中修改了被依赖的响应式数据。Chrome DevTools 的 Performance 面板录制一次交互，查看 “Vue” 标记是否密集重复出现，或展开调用栈观察 queueWatcher → flushSchedulerQueue → updateComponent 是否形成闭环。
computed 和 watch 中的隐式副作用是高危区
Vue 的响应式系统会自动收集依赖，但不会阻止你在 getter 或回调里改写依赖源。例如：
-
computed 内部赋值：
fullName: { get() { return this.firstName + this.lastName; }, set(val) { [this.firstName, this.lastName] = val.split(' '); } }—— 看似合理，但如果在模板中写了{{ fullName }}又在 set 里改了firstName，就会触发 fullName 重新求值，可能再次进入 set（尤其配合 v-model） -
watch 深度监听时直接修改原对象：
watch: { obj: { handler() { this.obj.key = 'new'; }, deep: true } }—— 修改行为会再次触发该 watch，形成循环
Patch 过程中组件更新不是立即执行，而是异步调度
Vue 2 的 patch 本身不直接更新 DOM，它只是比对 VNode 差异并生成更新函数。真正触发视图更新的是 组件的 render watcher 被触发 → 推入异步队列 → 下一 tick flush。关键机制在于：
Springboot Vue Builder
下载
从零开始编排 SpringBoot+Vue 全栈项目工作流，适用于新建全栈项目或完整脚手架请求，触发后依次调用 product‑spec‑builder（需求调研）等模块。
- 所有组件更新 watcher 统一由
queueWatcher管理，相同 watcher 多次触发只进队列一次（去重靠watcher.id） - 同一 tick 内多次数据变更，最终只执行一次
flushSchedulerQueue，避免重复 patch - 但若在
flushSchedulerQueue过程中（如组件 updated 钩子、或 watcher 回调里）又同步修改响应式数据，新 watcher 会立刻被 push 并在本轮末尾再次 flush —— 这就是死循环温床
排查与修复的核心原则
不要靠猜，要切断依赖链：
立即学习“前端免费学习笔记（深入）”；
- 用
console.trace()在 computed getter / watch handler 开头打点，看谁在反复调用 - 把疑似有问题的响应式字段临时改成
Object.freeze()，观察是否还循环 —— 若停止，说明该字段被意外修改 - 避免在响应式回调中直接改原数据；改之前加守卫，比如
if (newVal !== this.xxx) this.xxx = newVal - 复杂逻辑拆到 methods 中，用 $nextTick 延迟触发后续更新，让当前 patch 完全结束再介入
