React应用中直接使用Konva而非react-konva JSX写法有何弊端

先纠正一个普遍的认知偏差：用react-konva的JSX标签创建节点，根本不需要先拿Layer实例再调用find()找节点，直接给标签绑定ref就能拿到对应Konva节点的实例句柄，和你手动编程创建节点持有的引用没有任何区别，拖拽A同步移动B这类需要实时操作节点的场景，用ref拿实例操作的灵活性完全不打折。

举个最基础的用法示例：

import { useRef } from 'react';
import { Layer, Rect } from 'react-konva';

const SyncDragDemo = () => {
  const rectARef = useRef(null);
  const rectBRef = useRef(null);

  const handleDragMoveA = () => {
    const a = rectARef.current;
    const b = rectBRef.current;
    // 直接通过ref拿到节点实例操作，不需要任何查找逻辑
    b.x(a.x());
    b.y(a.y() + 60);
  };

  return (
    <Layer>
      <Rect ref={rectARef} x={100} y={100} width={50} height={50} fill="#ef4444" draggable onDragMove={handleDragMoveA} />
      <Rect ref={rectBRef} x={100} y={160} width={50} height={50} fill="#3b82f6" />
    </Layer>
  );
};

弃用JSX手动创建Konva节点的明确弊端 #

• 完全脱离React生命周期链路：手动new出来的Konva节点不会自动对接React的挂载、更新、卸载流程，组件卸载时你得自己手动销毁节点、解绑所有事件监听，忘写就会内存泄漏；React状态变更时也得自己写全量的属性同步逻辑，画布元素多、交互复杂之后，维护成本会涨得非常快。
• 事件逻辑割裂容易出低级bug：JSX写法下的事件绑定和普通React组件逻辑完全一致，onDragMove、onClick这类回调能直接访问组件内的最新状态、闭包变量；手动创建的节点得自己调用on()方法绑事件，既要处理闭包拿到旧状态的问题，卸载时还要记得逐个调用off()解绑，稍不注意就会出现事件重复触发、状态错乱的问题。
• 节点层级维护成本极高：JSX写法下节点的渲染顺序、嵌套层级直接和代码结构对应，条件渲染、列表渲染、Group嵌套的逻辑和写普通React组件没有区别；手动创建节点得自己维护节点的add/remove顺序、zIndex，要做动态增删节点、调整层级的时候，逻辑会散落在各处，非常难排查问题。

JSX写法的实际性能表现 #

JSX写法不仅不会带来额外的重绘开销，多数场景下性能比纯手动管理节点更稳定。

react-konva内部做了细粒度的属性diff，只有你传给JSX标签的属性真的发生变化时，才会调用对应Konva节点的更新方法触发局部重绘，不会出现全画布无意义刷新的问题。反而纯手动管理节点的时候，很多开发者图省事会在状态更新时直接触发整层重绘，或者做大量无效的重复属性赋值，反而会带来更多不必要的性能损耗。

内容的提问来源于stack exchange，提问作者Greg