Vue3 低代码拖拽为什么栈溢出：响应式循环的三个成因与改法

先看结论再说原因：低代码画布里的拖拽操作本身不会导致栈溢出，真正把调用栈压爆的是「你在响应式数据里写了一个会反过来触发自己的值」。典型形态有三种——拖拽过程中把规范化后的坐标写回同一个响应式对象、computed 或 watch 里既有读又有写形成闭环、以及递归组件缺了出口条件。浏览器给的信号也很清楚，JavaScript 引擎抛 RangeError: Maximum call stack size exceeded，Vue 自己则会先打出 Maximum recursive updates exceeded 的警告。下面按这三类成因逐个给出可复现的最小改动与验证方式。适用环境：Vue 3.4 及之后的 <script setup> 写法，事件基于 pointer 事件。

Vue3 低代码拖拽为什么会栈溢出？

先看结论

栈溢出的根因不是拖拽，而是响应式副作用直接或间接地改写了它自己的依赖。
Vue 先给警告 Maximum recursive updates exceeded，压不住才轮到引擎抛 RangeError。
DOM 节点不要放进 reactive，用 markRaw 或 shallowRef 包一层，否则代理层递归同样会失控。
递归渲染组件必须写明终止条件，否则每帧都在新建子组件。

排查顺序建议固定为：先看控制台警告是谁抛的，再顺着那条 watcher 找谁在写同一个对象。

一、先看清报错长什么样

两类报错不要混为一谈。第一类是 Vue 自己的保护性警告：

[Vue warn] Maximum recursive updates exceeded in component <Canvas>.
This means you have a reactive effect that is mutating its own dependencies
and thus recursively triggering itself.

它的含义很窄：某个响应式副作用正在改写它自己所依赖的数据。出现这条时，组件往往还能勉强动，但每一帧都在重复调度。

第二类是 JavaScript 引擎抛出的硬错误 RangeError: Maximum call stack size exceeded，意味着函数递归层数超过了调用栈上限，常见于自己调自己的递归函数没有出口。栈溢出本身指的就是这一类。

区分两者的意义在于定位方向：看到 Vue 的警告，去找 watch / computed / watchEffect；看到 RangeError，优先找真正的递归——递归组件、 mutual recursion 的工具函数、以及在响应式对象里放进去的 DOM 节点。

Vue 的响应式模型细节可以对照 Vue3 教程的依赖收集与派发更新两节再读一遍。

二、成因一：拖拽过程中把坐标写回同一个响应式源

低代码画布最常见的写法是在 pointermove 里跟随鼠标更新坐标，同时又用 watch 做吸附或边界收敛：

import { reactive, watch } from "vue";

const canvas = reactive({ items: [{ id: 1, x: 0, y: 0 }] });

watch(
  () => canvas.items.map((it) => [it.x, it.y]),
  () => {
    canvas.items.forEach((it) => {
      it.x = snap(it.x);
      it.y = snap(it.y);
    });
  },
  { deep: true }
);

function snap(n) {
  return Math.round(n / 8) * 8;
}

预期结果：鼠标移动时元素应该按 8 像素对齐移动。失败结果：控制台刷出 Maximum recursive updates exceeded，界面卡死。原因是 watch 的依赖正是 items 的坐标，而回调里又改写了坐标——吸附后的值与原值不同就再触发一次，能不能收敛全靠运气。

改法是把「用户输入」和「派生结果」拆成两份数据：原始坐标由事件写入，展示用的对齐坐标走 computed 派生，不在回调里回写源数据。

import { computed, reactive, markRaw } from "vue";

const canvas = reactive({ raw: { x: 0, y: 0 } });
const shown = computed(() => ({ x: snap(canvas.raw.x), y: snap(canvas.raw.y) }));

这个版本的依赖方向是单向的：只从 raw 流向 shown，不再有回写的那条边，递归自然不成立。拖拽结束后若要落库，在 pointerup 里一次性写入即可。

同类的第二个高频触发点，是把 DOM 节点或第三方画布实例塞进响应式对象：

const editor = reactive({ stage: null });
function onMounted(node) {
  editor.stage = node;              // 别这样写
  editor.stage = markRaw(node);     // 正确写法
}

reactive 对深层对象会递归代理，DOM 节点的结构极其庞大且有循环引用，包一层之后很容易触发栈溢出，也会拖慢拖拽帧率。用 markRaw 标记不参与代理，或者干脆用 shallowRef 存 DOM 引用，都是标准做法。

系统补齐 Vue3 的组合式 API 用法，可以跟着 Vue3 课程里的响应式章节练一遍。

三、成因二：watch 与 computed 里制造了闭环

第二大类成因是副作用的边界不清。判断准则很简单：computed 里绝不写它依赖的数据，watch 的回调里不要修改它的监听源。

一个反例：想在 computed 里顺便缓存一份最近一次的位置。

const lastPos = ref({ x: 0, y: 0 });
const panel = computed(() => {
  lastPos.value = { x: 10, y: 20 };   // 反例：computed 里写响应式数据
  return lastPos.value.x;
});

预期结果：页面渲染时被 Vue 拦下，或出现不可预期的重复计算。实际后果取决于版本，但方向一定是错的——computed 应当是纯派生。正确做法是把它降级成一个明确的函数，在事件回调里调用。

还有一类隐蔽闭环来自双向依赖：A 的 watch 写 B，B 的 watch 又写回 A。这种写法在代码量小的时候看不出来，一旦吸附规则复杂起来就会连滚。处理方式是引入单一数据源，或者加一个收敛判断：

watch(() => state.x, (v) => {
  if (Math.abs(v - state.targetX) < 1) return;  // 差值已收敛，不再写
  state.targetX = v;
});

用差值判断是否还需要继续写，本质上是给递归加一个出口条件。加出口条件并不丑，比让数据自洽的隐式约定可靠得多。

按控制台报错类型定位三类成因的判断路径

这一层会反复用到闭包与递归调用的基本功，需要补可以看 JavaScript 教程里关于调用栈的部分。

四、成因三：递归组件缺少出口条件

低代码画布经常用「节点树递归渲染」来表达嵌套：每个组件渲染自己的 children。此时出口条件不是可选项，而是必须项。

<script setup>
defineProps({ node: { type: Object, required: true } });
</script>

<template>
  <div class="node">
    <span>{{ node.name }}</span>
    <NodeItem
      v-for="child in node.children"
      v-if="node.children && node.children.length"
      :key="child.id"
      :node="child"
    />
  </div>
</template>

预期结果：按数据层级渲染出树形结构。失败结果：数据结构里若存在父子互相引用（这在拖拽交换节点时很容易出现），递归永远不会停，直接 RangeError: Maximum call stack size exceeded。

同一段模板里 v-for 与 v-if 写在一个元素上是 Vue 2 时代的写法，Vue 3 应当用 template 包一层或者给 children 兜底为空数组。改法是把边界放进数据里，而不是散落在模板各处：

function normalizeTree(raw) {
  const seen = new Set();
  return raw.children.filter((c) => !seen.has(c.id) && seen.add(c.id));
}

递推遍历时用一个 Set 记录走过的 id，既能防止环，也能顺手去重。这类保护应当放在数据入库之前，而不是渲染的时候临时补救。

拆派生值、加收敛出口、入库前剪环三条落地措施

动手核对清单

前置：准备一个 Vue3 项目，把上面三段最小示例分别放进去。
命令：运行 npm run dev 启动本地预览。
运行：在画布里连续拖动同一个元素 10 秒，观察控制台与帧率。
检查：确认不再出现 Maximum recursive updates exceeded 与 RangeError 两类输出。
预期：拖拽过程保持 60 帧左右，松手后位置一次性落库。
失败：若仍报栈溢出，先检查 DOM 是否被写进了 reactive，再看 watch 回调有没有回写监听源。
验证：用一个含互相引用的坏数据跑一遍 normalizeTree，确认没有无限递归才算闭环。

以上为本机的常规操作流程，未在本文写作环境实际执行，输出为预期结果。

总结

拖拽导致的栈溢出，本质是响应式副作用改写了自己的依赖，先盯 watch 与 computed。
输入与派生分离：原始坐标可被写，对齐坐标走 computed，别回写同一个源。
DOM 节点与第三方实例一律 markRaw 或 shallowRef，不进深层代理。
递归组件必须写明出口，最好在数据入库前就用 Set 剪掉环。

常见问题

Q：控制台只有警告、没有报错，也要处理吗？

要。Maximum recursive updates exceeded 说明 Vue 已经在替你踩刹车，此时界面看起来能动，实际每一帧都在重复调度，掉帧和偶发的栈溢出只是时间问题。看到这条警告就按第二、三节的反向依赖排查，不要等它升级成 RangeError。

Q：为什么加了 deep: true 之后问题才出现？

deep 会让 watcher 递归监听对象内部的所有层级，等于把依赖面扩大到整棵树。拖拽这种高频写入场景下，deep 监听一个不断被改写的对象最容易触发递归更新。处理方式是缩小监听范围到具体字段，或者干脆把派生逻辑搬进 computed。

Q：用 Vuex 或 Pinia 存画布状态会不会好一点？

不会自动好。状态库解决的是跨组件共享，不能消除「同一个写操作触发同一个依赖」这件事。换成外部 store 之后依然要遵守单向数据流：事件改 store，视图从 store 派生，派生值不回写。

延伸学习

Vue 3 新特性解析：把响应式 API 的新特性串起来过一遍，适合理解本文第二节提到的依赖方向。
Vue 响应式黑洞：把 Vue 里几类响应式引发的问题连起来看，本文第二节的循环正属于其中一类。
Vue3course：组件与响应式体系的练习材料，本文的递归渲染部分可以在这里找到配套练习。