React Flow边缘丢失与错位问题：基于Hooks的状态管理重构实践

做流程编辑器最怕什么？不是节点拖不动，而是你辛辛苦苦拉好的连线，一刷新、一切Tab、一拖某个节点，它说没就没，或者线头直接插进节点身体里。最近我把公司的 React Flow 流程编辑器彻底重构了一遍，核心就一句话：把节点和边缘的状态管理从组件里抽出来，全部收进 Hooks 层。重构完以后，边缘丢失和错位这两类问题从“隔三差五报一次bug”变成了“很久没再管过”。

这篇文章我尽量把问题根源讲透，再把 Hooks 重构的方案一步步拆开，包含可以复制的代码和参数处理思路。用的例子基于@xyflow/react（React Flow v12 之后的包名），如果你还在用 v11，API 上稍微对照一下即可，思路完全通用。适合正在做流程编排、图编辑器、低代码连线功能，并且被“边缘不稳定”折磨过的人。

1. 问题画像：边缘丢失与错位的四种典型现场

先说现象。边缘（Edge）在 React Flow 里就是节点之间的那根连线，数据模型很简单，一个source（起始节点 id）、一个target（目标节点 id），再加上两个 handle 的 id 就能画出来。但“简单”不代表“稳定”，我整理了实际项目里反复出现的四类现场，你先对号入座。

1.1 现场一：组件一重渲染，连线直接消失

最常见的情况是父组件里某个状态变了，整个流程编辑区域被重新渲染，结果节点还在，边一根都不剩。你再检查代码，发现edges数组里数据还在，但 React Flow 就是显示不出来。

这种通常是边缘数据根本没有传给 React Flow，或者传了但 React Flow 在内部做数据合法性校验时，把“失效”边缘丢掉了。React Flow 不会把所有你的edges都照单全收，它会要求每条 edge 的source和target必须能对应到真实存在的节点，对不上就直接丢。如果你在父组件渲染链条的某个地方把edges传丢了，或者节点数组和边缘数组不是同一份数据源，就会触发这种“数据还在、图面空了”的诡异状态。

1.2 现场二：节点增删后，边缘指向了“不存在”的地方

第二个高频场景是流程运行过程中动态增删节点。比如你删掉中间一个节点，然后发现原本连到它后面的几条边全没了，或者连到了完全错误的节点上。

这个问题的根源往往是节点 id 不稳定。有人喜欢用数组下标当 id，有人用Date.now()或者Math.random()，更有人图省事直接在渲染函数里生成 edges。节点一增删，id 一变，边缘的source和target对不上了，React Flow 只能做丢弃处理。这种情况不是 React Flow 的 bug，纯粹是你给边缘提供了“虚假的引用地址”。

1.3 现场三：布局刷新后，线还在但位置全错了

第三类问题最让人头疼。线没丢，但线的起点和终点偏移了，线头扎在节点的左半边，或者从节点上方穿过去，看起来像是边缘层和节点层坐标没对齐。

这类错位绝大多数和异步布局计算有关。我们的编辑器接入了自动布局算法（dagre、elkjs 这类），异步拿到新坐标后更新节点position，但 React Flow 内部需要根据节点新坐标去重新计算边缘路径。如果更新时机不对，比如节点才更新一半、或者节点尺寸还没测量完就去渲染边缘，路径自然对不上。还有一种隐藏场景：自定义节点内部结构发生了变化，Handle 的数量或者位置变了，但 React Flow 内部持有的节点信息还是旧的，边缘起终点也就跟着错了。

1.4 现场四：Tab 切换或弹窗关闭后，整张图状态清零

还有一种“边缘丢失”是整体性的。流程编辑器放在 Modal 弹窗里，或者放在 Tab 页里，弹窗关掉再打开，图全空了，得重新加载一次数据。

问题在于组件卸载时，React Flow 内部的状态和你的节点、边缘数据一起被销毁了。React Flow 在非受控模式下会把节点位置、缩放、边缘路径都存在组件内部，组件卸载等于把现场全部清空。如果数据没有持久化到上层状态，看起来就是“边缘丢失”。其实边缘没丢，是整张图的状态都丢了。

2. 根源分析：React Flow 边缘为什么这么“娇气”

要解决问题，光知道现象不够，还得搞明白 React Flow 内部是怎么处理边缘的。在我看来，边缘之所以容易出问题，核心有三个原因。

2.1 边缘是“挂靠”在节点两端 Handle 上的

React Flow 的边缘本身没有坐标数据，它依赖两侧节点的 Handle 位置来推算路径。渲染时，系统内部会读取source节点上指定 Handle 的全局坐标，再读取target节点上指定 Handle 的全局坐标，然后在这两点之间画一条贝塞尔曲线。

这意味着：

• 只要source或target引用的节点不存在，边缘就画不出来。
• 只要 Handle 的 id 找不到，边缘就画不出来。
• 只要节点坐标更新了，但边缘层没有重新计算，路径就是旧的。

理解了这一点，你会发现大部分边缘问题的根源都不是“边缘本身”，而是它依赖的节点、Handle、坐标链路出了问题。用个不恰当但好懂的类比：边缘是桥，节点是桥墩，桥墩歪了、塌了、被挪走了，桥自然不可能还是那座桥。

2.2 渲染层与数据层分离，谁先谁后很容易出问题

React Flow 组件在渲染时会做数据快照，节点数组和边缘数组作为 props 传入后，内部会维护一套基于传入数据的派生状态。如果你用的是非受控模式（也就是节点和边缘只通过defaultNodes、defaultEdges传给组件，之后完全靠内部维护），那么数据的“真相”在 React Flow 内部，你从外部拿不到；如果中途又穿插了部分受控操作（比如你通过setNodes改了位置，但没有同时改边缘），两边就会脱节。

最典型的错误是同时用了两套真相来源：一部分节点由外部 state 管理，另一部分由 React Flow 内部状态管理，边缘还挂在第三方状态里。这种设计下，边缘丢失和错位几乎是必然结果，因为任何一个状态源更新，其他状态源都感知不到。

2.3 Reactive Store 机制与受控状态的冲突

React Flow 内部使用 zustand 这样的响应式 store 来管理视图状态（缩放、偏移、选中态、hover 态）。它会把用户传入的nodes和edges同步到 store 中。当用户拖拽节点时，React Flow 会更新 store 里的节点坐标，然后回调onNodesChange。

问题在于这套机制有严格的时序要求。如果你在onNodesChange里对节点做了过滤、排序、id 重写等操作，但没有保证边缘数据同步更新，store 里的节点和边缘就可能在某一帧出现不一致。边缘路径计算是在渲染时根据 store 里的节点坐标和边缘引用同步进行的，只要数据源短暂不一致，就会出现“节点已经拖走了，线还留在原地”的错位现象，严重时边缘直接丢失。

所以结论不是“React Flow 娇气”，而是它严格依赖一条完整、一致、同步的数据链路。链路断在哪一环，问题就出在哪一环。

3. Hooks 重构方案：把散落状态收拢成一层可控数据流

我这次重构的整体思路，是把所有节点和边缘状态收拢到一个自定义 Hook 里，由这个 Hook 对外暴露稳定的操作函数，任何组件通过函数来修改图数据，而不是直接改数组。这套方案做下来，边缘相关的问题明显少了很多。

3.1 重构第一步：用一个 useFlowGraph 统一收口节点和边缘

我先定义了一个useFlowGraph自定义 Hook。它内部用useReducer管理节点和边缘，对外只暴露state和一组操作函数。操作函数内部保证“节点变化时，边缘里的引用同步一致”，从机制上杜绝引用失效。

import { useCallback, useReducer } from 'react'; import type { Node, Edge } from '@xyflow/react'; type FlowState = { nodes: Node[]; edges: Edge[]; }; type FlowAction = | { type: 'setNodes'; nodes: Node[] } | { type: 'setEdges'; edges: Edge[] } | { type: 'addNode'; node: Node } | { type: 'removeNode'; nodeId: string } | { type: 'addEdge'; edge: Edge } | { type: 'removeEdge'; edgeId: string }; function flowReducer(state: FlowState, action: FlowAction): FlowState { switch (action.type) { case 'setNodes': return { ...state, nodes: action.nodes }; case 'setEdges': return { ...state, edges: action.edges }; case 'addNode': return { ...state, nodes: [...state.nodes, action.node] }; case 'removeNode': { const nodes = state.nodes.filter((n) => n.id !== action.nodeId); const edges = state.edges.filter( (e) => e.source !== action.nodeId && e.target !== action.nodeId ); return { nodes, edges }; } case 'addEdge': return { ...state, edges: dedupeEdges([...state.edges, action.edge]) }; case 'removeEdge': return { ...state, edges: state.edges.filter((e) => e.id !== action.edgeId) }; default: return state; } } export function useFlowGraph(initialNodes: Node[], initialEdges: Edge[]) { const [state, dispatch] = useReducer(flowReducer, { nodes: initialNodes, edges: initialEdges, }); const addNode = useCallback((node: Node) => dispatch({ type: 'addNode', node }), []); const removeNode = useCallback((nodeId: string) => dispatch({ type: 'removeNode', nodeId }), []); const addEdge = useCallback((edge: Edge) => dispatch({ type: 'addEdge', edge }), []); const removeEdge = useCallback((edgeId: string) => dispatch({ type: 'removeEdge', edgeId }), []); const setNodes = useCallback((nodes: Node[]) => dispatch({ type: 'setNodes', nodes }), []); const setEdges = useCallback((edges: Edge[]) => dispatch({ type: 'setEdges', edges }), []); return { nodes: state.nodes, edges: state.edges, addNode, removeNode, addEdge, removeEdge, setNodes, setEdges, }; }

这个 Hook 看起来简单，但解决了两个关键问题。

第一，所有状态修改都收敛到一个 reducer 里，没有绕道修改。以前大家习惯在组件里直接setNodes(prev => [...prev])，然后在另一个地方又setEdges(...)，两个数组完全靠程序员自觉保持同步。重构后，删除节点这一个动作会同时清理边缘，不用再到处找哪里漏了。

第二，addEdge内部接了一层dedupeEdges去重。这一点从机制上防止了重复边缘让人头痛的问题，下面展开说。

3.2 重构第二步：边缘数据去重与稳定性设计

边缘丢失的对立面是边缘重复。你拖一次连接线，回调里addEdge被触发两次，结果同一对节点之间冒出两根完全重叠的线，视觉上像一根线但选中时明显能看出两条。这种问题非常常见，根源就是边缘数据没有做唯一性校验。

我在重构里写了一个去重函数，把“相同连接关系”的边缘合并成一条。判断逻辑不是只看source和target，还要把 Handle id 也带进去，因为同一个节点可能有多个连接点，从 A 节点的输出 1 连到 B 节点的输入 2，和从 A 节点的输出 2 连到 B 节点的输入 1，不是同一条边。

function dedupeEdges(edges: Edge[]): Edge[] { const seen = new Set<string>(); return edges.filter((edge) => { // 自环没有意义，直接干掉 if (edge.source === edge.target) return false; const key = `${edge.source}->${edge.target}->${edge.sourceHandle ?? 'null'}->${edge.targetHandle ?? 'null'}`; if (seen.has(key)) return false; seen.add(key); return true; }); }

这套去重逻辑我把它放在 reducer 的addEdge分支里，而不是放在显式的按钮触发处。原因是 React Flow 的onConnect回调在某些版本和交互模式下可能触发多次，只有在校验入口集中兜底才能彻底防住。

另外要强调一个容易被忽略的点：边缘的 id 也要稳定。如果 edge 的 id 在每次渲染时都用Math.random()生成，React Flow 内部的动画、选中态、删除操作都会出问题。重构后我给每条新边缘生成一个确定性的 id，规则是${source}-${target}-${Date.now()}，这样既稳定又不至于在多条同源同目标边缘时冲突。

3.3 重构第三步：实例与视图状态分离，布局计算放到 Hooks 里

第三部分是解决“错位”问题的关键。错位的本质是节点坐标变了，但视图层没有正确回写。我这里的做法是把 React Flow 的实例操作和节点数据处理彻底分开：

• 节点数据、边缘数据由useFlowGraph管理。
• React Flow 实例（screenToFlowPosition、fitView、setCenter这些视图方法）由useReactFlow在组件内部获取。
• 异步布局计算的代码放在单独的useAutoLayoutHook 里，不写在组件体内。

其中最重要的一点是：布局计算完成后，必须通过setNodes用全量新数组替换旧数组，绝对不能原地修改节点的position属性。React Flow 对节点数组的更新依赖引用变化，你直接改node.position.x = xx，store 里检测不到变化，边缘路径就不会重新计算。

我的useAutoLayout大概是这样的结构：

import { useEffect } from 'react'; import { useReactFlow, type Node, type Edge } from '@xyflow/react'; type LayoutResult = { nodes: Node[]; edges: Edge[]; }; // 你需要实现一个 layoutGraph，内部调 dagre/elkjs，或者自己写分层算法 async function layoutGraph(nodes: Node[], edges: Edge[]): Promise<LayoutResult> { // 这里是关键：布局算法需要知道节点宽高，所以要先取到 nodes 的 measured 尺寸 const layoutNodes = nodes.map((node) => ({ ...node, width: node.measured?.width ?? 200, height: node.measured?.height ?? 60, })); // 调 dagre 或 elkjs，返回带 position 的新节点数组 return { nodes: layoutNodes, edges }; } export function useAutoLayout(nodes: Node[], edges: Edge[], setNodes: (nodes: Node[]) => void) { const { fitView } = useReactFlow(); useEffect(() => { let cancelled = false; layoutGraph(nodes, edges).then(({ nodes: layoutedNodes }) => { if (cancelled) return; setNodes(layoutedNodes); // 等渲染一帧后再 fitView，确保边缘路径已经按新坐标计算完 requestAnimationFrame(() => fitView({ padding: 0.2, duration: 200 })); }); return () => { cancelled = true; }; }, [edges.length]); // 注意：不要把 nodes 整个塞进依赖数组，否则拖拽节点也会触发重排 }

这里的依赖数组选择很关键。我刻意只依赖edges.length，这样自动布局只会在连接关系变化时触发，节点拖动不会引发整图重排。如果某些业务要求“拖动后重新布局”，你可以自己调整为依赖其他信号，但我建议至少不要每次都重算，否则用户体验会非常差。

布局后错位还有一个隐蔽但很常见的原因：布局算法拿不到节点真实尺寸。React Flow 里节点尺寸是渲染后测量得到的，放在node.measured.width和node.measured.height上。如果自定义节点的内容会动态变化（比如折叠展开），测量值可能过期。我在layoutGraph里做了兜底，拿不到就按 200x60 算，同时建议自定义节点组件里尽可能给外层容器一个固定宽度基线，减少测量波动。

4. 实操过程：从命令式补丁到声明式数据流的完整改造

画了这么多理论，具体改造长什么样？我把重构前后的核心代码都贴出来，你可以对比着看差别。

4.1 改造前的问题代码（bad smell）

这是我在线上抓到过的问题版本，典型的边丢边错边漏：

export function FlowEditor() { const [nodes, setNodes] = useState<Node[]>(initialNodes); const [edges, setEdges] = useState<Edge[]>(initialEdges); const reactFlowInstance = useRef<ReactFlowInstance | null>(null); // 隐患1：用数组索引作为节点 id const addNode = () => { const newId = `node-${nodes.length}`; setNodes((prev) => [...prev, { id: newId, position: { x: 100, y: 100 } }]); }; // 隐患2：删除节点时只删节点，不清理关联边缘 const removeNode = (id: string) => { setNodes((prev) => prev.filter((n) => n.id !== id)); }; // 隐患3：onConnect 里直接 setEdges，没有任何稳定性和去重处理 const onConnect = useCallback( (params: Connection) => { const newEdge = { ...params, id: `edge-${Date.now()}` }; setEdges((prev) => [...prev, newEdge]); }, [setEdges] ); // 隐患4：手动布局，直接改 node 对象属性 const handleLayout = () => { nodes.forEach((node) => { node.position = { x: node.position.x, y: node.position.y + 100 }; }); setNodes([...nodes]); // 数组是新的，但 node 引用没变，React Flow 检测不到节点坐标变化 }; return ( <ReactFlow nodes={nodes} edges={edges} onConnect={onConnect} onInit={(instance) => { reactFlowInstance.current = instance; }} /> ); }

这段代码包含了我在生产环境看到过的绝大部分坏味道。数组下标当 id、删除节点不联动删边、connect 时直接 push、布局时原地改对象。等节点数量一多、操作一频繁，边缘丢失和错位自然就来了。

最隐蔽的是“隐患4”那个写法。setNodes([...nodes])确实创建了新数组，但数组里的node对象还是原来那些引用。React Flow 做浅比较时发现数组变了会走更新流程，但节点对象本身引用没变，内部的position变更不会被 React 触发重新渲染。结果就是你在nodes变量里看到的坐标是对的，但界面上节点和边缘纹丝不动，等你手动随便点一下页面，强制重绘后才跳过去。这种“看起来边缘错位”的 bug 最难排查，因为你打日志看数据都是对的。

4.2 重构后的核心实现

重构后，组件本身瘦身成了很薄的一层：

import { useFlowGraph, useAutoLayout } from './hooks/useFlowGraph'; import { ReactFlow, ReactFlowProvider, Controls, Background } from '@xyflow/react'; import '@xyflow/react/dist/style.css'; import type { Node, Edge } from '@xyflow/react'; const initialNodes: Node[] = [ { id: 'start', type: 'custom', position: { x: 0, y: 0 }, data: { label: '开始' } }, ]; const initialEdges: Edge[] = []; function FlowCanvas() { const { nodes, edges, setNodes, setEdges, addEdge, removeNode, } = useFlowGraph(initialNodes, initialEdges); // 自动布局只在边缘数量变化时触发 useAutoLayout(nodes, edges, setNodes); const onConnect = useCallback( (connection: Connection) => { const edge: Edge = { ...connection, id: `edge-${connection.source}-${connection.target}-${Date.now()}`, }; addEdge(edge); }, [addEdge] ); const onNodesChange = useCallback((changes: NodeChange[]) => { setNodes((prev) => applyNodeChanges(changes, prev)); }, [setNodes]); const onEdgesChange = useCallback((changes: EdgeChange[]) => { setEdges((prev) => applyEdgeChanges(changes, prev)); }, [setEdges]); const onNodeDoubleClick = useCallback( (_: React.MouseEvent, node: Node) => { removeNode(node.id); }, [removeNode] ); return ( <div style={{ width: '100%', height: '800px' }}> <ReactFlow nodes={nodes} edges={edges} onConnect={onConnect} onNodesChange={onNodesChange} onEdgesChange={onEdgesChange} onNodeDoubleClick={onNodeDoubleClick} fitView proOptions={{ hideAttribution: true }} > <Controls /> <Background /> </ReactFlow> </div> ); } export default function FlowEditor() { return ( <ReactFlowProvider> <FlowCanvas /> </ReactFlowProvider> ); }

注意几个关键点。

第一，useFlowGraph返回了setNodes和setEdges，这个看起来像是把旧的“直接 setState”又放出来了，但意义完全不同。这里的setNodes实际上 dispatch 到 reducer，并且 reducer 里的setNodes分支只负责整体替换数组，没有其他副作用。关键作用是把“状态修改入口”收拢到一个稳定引用上，组件每次渲染拿到的都是同一个函数引用，避免因为函数地址变化导致 React Flow 内部重复订阅或意外重新渲染。

第二，onNodesChange和onEdgesChange我都用官方提供的applyNodeChanges和applyEdgeChanges去处理。这两个工具函数是 React Flow 的核心，v11 和 v12 都有，负责把拖拽、选中、删除等交互事件翻译成最终的节点/边缘数组。很多边缘错位问题其实是因为有人在这里只对 nodes 做了处理，没处理dimensions的变化，或者对 edges 的变化忽略了source/target关联信息。直接用官方工具函数是最省心的做法。

第三，我把自定义节点的宽高前移到了一个独立设计里。在自定义节点组件中，根节点统一用一个minWidth和minHeight兜底，且 Handle 的位置尽量两侧对齐，不放在内容中部。这样可以保证即使某些内容还没渲染出来，React Flow 测量到的节点尺寸也不至于偏到影响边缘路径。

4.3 布局回写与边缘坐标更新的参数处理

自动布局最容易踩的坑是“布局算完，节点坐标更新了，但边缘路径没有重新计算”。这不是 React Flow 的 bug，而是布局库返回结果没有正确写入节点数据。

我之前在 production 环境遇过一个特别迷惑的问题：用 elkjs 做分层布局，布局完以后，节点位置是对的，边缘却是从旧位置连出来的，整个图画成了蜘蛛网。查了半天发现，elkjs 返回的节点数组顺序是打乱的，而且返回的坐标是绝对坐标，但我在合并数据时用了“按 id 原位覆盖”的逻辑，有些节点 id 匹配失败，导致部分节点坐标没更新。React Flow 发现约一半的节点坐标没变，就只重算了部分边缘路径，整体看起来就是错位的。

解决方法是布局结果合并时必须全量生成新节点对象，并给每个节点显式赋值position：

const layoutedNodes = layouted.map((item) => { const originalNode = nodes.find((n) => n.id === item.id); return { ...originalNode, position: { x: item.x, y: item.y }, } as Node; });

这里必须...originalNode展开而不是originalNode本身，目的就是创建新的对象引用，让 React Flow 内部能感知到“这个节点的数据变了”。同时要确保position是{ x, y }结构，i 不能传成{ left: x, top: y }，React Flow 内部是按position.x/position.y读取的，字段名对不上它也不会报错，只会表现得像边缘错位。这个坑我帮同事排查过，前端工具类框架的字段约定就是这样，错了不提示，只能靠文档和经验对照。

另一个参数处理细节是fitView的时机。布局完成后别立刻调用fitView，最好等一帧。因为节点position更新后，React Flow 要经过一次渲染才能计算新的边缘路径和整体包围盒，此时立刻 fitView 会拿到旧的包围盒坐标。我在代码里用requestAnimationFrame包了一层，实测下来基本没再遇到过布局后边缘偏移出视野或者整体缩放比例不对的问题。

5. 常见问题排查与避坑实录

最后这部分是我最想写的，因为很多问题是文档里搜不到的，只能靠踩坑。

5.1 常见问题速查表

我把重构过程中遇到的和身边同事遇到的典型问题整理成一个速查表，碰到类似现象可以先来这里对照。

5.2 好几个容易忽略的细节

第一个细节是node.measured的使用时机。React Flow v12 的节点对象上有一个measured字段，保存了渲染后的实际宽高。但这个字段是在节点真正渲染后才会更新，初始状态是undefined。如果你在nodes的初始值里就想去读node.measured.width，拿到的会是空。正确的做法是在自定义节点的data回调里指定初始widthstyle，或者像我在layoutGraph里做的那样，给一个默认值兜底。

第二个细节是onConnect回调的触发次数。React Flow 的连线交互，用户从源 Handle 拖到目标 Handle，正常情况下onConnect只触发一次。但如果你的画布里有多个 ReactFlowProvider，或者组件被挂载了多层，事件冒泡可能导致回调触发多次。去重逻辑放 reducer 入口而不是调用处，就是为了兜住这种“你以为只调一次，实际调了两次”的情况。

第三个细节是关于边缘的animated属性。很多人喜欢给边缘加流动动画，让流程方向更明显。但如果你在布局后更新节点坐标且动画开着，边缘状态会有短暂的重绘闪烁。这不是大问题，但如果你敏感，布局期间可以先把animated置为 false，布局完成后再恢复。

第四个细节是删除节点的确认。我用onNodeDoubleClick做删除，但生产环境里误触导致删掉一整个子图的问题发生过好多次。后来我把删除逻辑改了：删除前先把关联的节点和边缘做一个确认动作，如果子图太大就弹窗确认。这不影响边缘稳定性，但能避免用户一把把所有连线都删光之后来骂“线全丢了”。有些“边缘丢失”其实是人删的，只是用户自己没意识到。

第五个细节是关于defaultEdgeOptions。如果项目里所有链接线都是同一种类型（curved、step、straight），可以在 React Flow 组件上统一配置defaultEdgeOptions，避免每个addEdge时都要写一遍样式字段。这个配置还能统一type和markerEnd，减少数据字段遗漏导致边缘渲染成默认直线的情况。

第六个细节是自定义节点里的 Handle 必须设置id，尤其是节点上有多个输入输出时。如果 Handle 不设置 id，React Flow 内部用默认值null作为标识，当节点有多个 source Handle 时，onConnect返回的sourceHandle会全是null，导致你根本无法区分连线是从哪个口拉出来的。重构后我在所有自定义节点里显式给 Handle 设置id，并且确保和边缘数据里的sourceHandle完全一致。这一步做不好，边缘会画到错误的连接点上，看起来就是“错位”。

6. 写在最后的一点体会

这套 Hooks 重构方案上线到现在已经跑了半年多，最直观的变化是群里关于“线不见了”“线画歪了”的反馈基本清零。我自己的体会是，React Flow 本身的状态管理机制设计得挺严谨，大部分边缘问题都是使用者的数据流没理顺，导致框架内部的依赖链条断裂。

如果你现在也在被边缘问题折磨，我建议你先别急着加补丁，花半天时间把节点和边缘的数据流完整梳理一遍：谁在什么时机创建节点、谁在什么时机创建边缘、删除节点时有没有清理边缘、布局算法返回的数据是不是真的把每个节点都生成了新引用。把这几个问题回答清楚了，八成的问题都能自己定位到。

最后再分享一个小技巧：我在开发环境给useFlowGraph的 reducer 加了一个 dev 日志，每次 dispatch 都打印动作类型和当前节点/边缘数量。排查“边缘莫名丢失”的问题时，这个日志能帮你瞬间定位是哪一次操作导致的。把状态变更日志打出来，很多 bug 的复现和定位会快很多。