Ru果你是一位资深的B站用户，或许在某个深夜刷视频时曾对着屏幕上转圈的Loading图标发呆，甚至忍不住在贴吧里发帖吐槽：“为什么我在B站kan视频卡顿特严重？真成PPT了！”有人会建议你关掉弹幕，有人让你换Chrome浏览器，甚至还有人让你去检查是不是Flash插件该升级了。这些关于网络波动、硬件解码或是校园网限制的讨论，构成了B站技术生态中充满烟火气的一面。

然而在用户感知的“卡顿”之外B站的工程师们曾面临着另一场geng为隐蔽、也geng为棘手的技术“卡顿”。这场危机并非发生在播放器里而是发生在内容创作的源头——专栏编辑器中。今天我们就来扒一扒B站富文本编辑器演进史中，那段从“伪造”走向“真实”的硬核往事，kankan视频卡片技术究竟经历了怎样的革新。

Quill时代的“收银小票”与无奈的妥协

回望B站富文本编辑器的演进史，我们经历了一个从“无”到“有”，再从“有”到“优”的过程。我们解决了基本的文本编辑需求；后来进入Quill时代，虽然引入了先进的Delta数据模型，但也埋下了新的隐患。

Quill使用的是Delta数据模型。这玩意儿本质上是一个线性的操作记录，就像一张长长的收银小票🧾。这种结构对于纯文本编辑来说简直丝般顺滑，但一旦遇到复杂的嵌套结构，它就显得力不从心了。想象一下你想在这张薄薄的小票中间塞进一个立体、复杂的“视频播放器盒子”？太难了！Delta天生就是扁平的，它hen难描述复杂的嵌套结构。

为了在Quill这个不支持复杂Block Node的编辑器里塞进一个视频卡，当年的工程师们可是绞尽脑汁，Zui终设计了一套后续发现极其痛苦的“Canvas截图大法”。这听起来像是一个江湖骗术，但当时却是我们唯一的救命稻草。

令人崩溃的“截图大法”

你可Neng经历过这样的场景：在专栏里粘贴了一个视频链接，然后kan着Loading转圈圈，心里默数两秒，“啪”的一下编辑器里出现了一个视频卡片。kan起来hen美？别急着夸。当你试图点击播放时发现它毫无反应；当你试图修改标题时发现根本选不中文字。这哪里是视频卡片，这分明就是一张死图！

为了实现这个“障眼法”，我们被迫构建了一条极其繁琐的链路：

1. 隐式渲染： 在浏览器可视区域外用HTML偷偷画一个临时的卡片DOM。

2. Canvas 截图： 调用html2canvas咔嚓一下把这个DOM变成Canvas。为了保证清晰度，通常需要设置scale参数。

3. 图片生成： 将Canvas导出为Base64图片。

4. 上传替换： 把图片上传到CDN，Zui后在编辑器里插一个静态的标签。

说实话，每次写这段代码时我的内心dou是崩溃的。这种Zuo法虽然暂时解决了跨平台兼容问题，但代价是沉重的：

性Neng黑洞： 整个“API请求 → 绘制 → 截图 → 上传”的链路平均耗时2秒以上。严重打断写作心流。

交互性丧失： 这仅仅是一张死图。所谓“所见即所得”其实是“所见即图片”。

数据死锁： 卡片上的播放量、弹幕数永远停留在插入的那一刻。Ru果视频后续爆火，卡片信息也不会geng新，甚至误导读者。

存储浪费： 每一张生成的卡片图片dou需要占用CDN空间，随着文章数量增长，这是巨大的隐形资源浪费。

技术选型的终极博弈：为何是ProseMirror？

既然痛点找准了那就开干。在决定彻底抛弃Quill之前，我们对市面上的富文本技术方案进行了一次深度摸底。从底层技术演进来kan，Web富文本编辑器主要经历了三个维度的跃迁。

在L1的终极对决中，面对生态优秀的Lexical和老牌的Draft.js，以及底层极其强大但API学习曲线陡峭的ProseMirror，我们Zui终选择了Tiptap + ProseMirror的组合拳。

为什么是这套组合？Tiptap作为基于ProseMirror构建的Headless框架，完美继承了其强大的文档树和Schema规范，同时提供了一层极其优雅的API封装。这套“底层稳健兜底，上层开发丝滑”的设计，斩断了特定UI框架的强依赖，成为我们完成这次降维打击的Zui优解。

与Quill的“收银小票”不同，ProseMirror使用的是Document Model，它就像是乐高积木。你Ke以搭建一个名为“视频卡”的积木块，然后在里面随意嵌套“标题积木”、“封面积木”甚至“播放器积木”。这种树状结构天然就支持复杂的Block Node。

// ProseMirror Tree: 结构化的树形数据
{
  "type": "doc",
  "content":  },
    {
      "type": "videoCard", // 独立的块级节点
      "attrs": { "bvid": "BV1xx..." },
      "content":  // Ke以继续嵌套其他节点
    }
  ]
}

架构重构：NodeView与组件分离

我们设计了全新的“编辑器-组件分离”架构，利用ProseMirror强大的NodeView机制，彻底重构了卡片系统。在这个架构中，编辑器不再负责具体的UI渲染，而是专注于文档结构的管理。NodeView充当了“桥接”的角色。

我们需要告诉编辑器，“视频卡”这个积木长什么样，有什么属性。

// schema/video-card.ts
const VideoCard = Node.create({
  name: 'videoCard',
  group: 'block',     // 声明我是块级节点
  atom: true,         // 💡 关键点：原子化
  draggable: true,    // 可拖拽
  // 定义数据属性
  addAttributes {
    return {
      card_style: { default: CardStyle.NORMAL },   // 卡片风格
      info: { default: {} },             // 业务数据
      status: { default: 'loading' }          // loading | loaded | error
    };
  },
  // 解析规则：怎么从 HTML 读出来
  parseHTML {
    return ' }]
  },
  // 渲染规则：怎么存成 HTML
  renderHTML {
    return 
  }
})

接下来是重头戏——NodeView。它是连接ProseMirror数据层和UI渲染层的桥梁。我们要在这里把UI组件挂载上去。通过Tiptap + ProseMirror的现代化技术栈，我们成功将“低保真”的绘图式卡片，进化为具备完整生命周期、状态管理和复杂交互的“应用级”组件。这不仅解决了当下的性Neng痛点，geng为未来引入投票、互动游戏等geng复杂的业务卡片奠定了坚实的基础。

我们抽象了BaseCard基类，利用策略模式处理不同类型的卡片渲染。无论是视频卡、专栏卡还是投票卡，dou复用了同一套生命周期管理逻辑，代码复用率得到了显著提升。

性Neng与体验的平衡艺术

技术世界没有银弹。当我们为“极速插入”和“真实交互”欢呼时隐秘的代价也随之而来——展示态的性Neng崩盘风险。旧方案虽然插入慢，但在运行时只是一张死图，文章里塞入100个卡片依然Neng丝滑滚动。但新方案的每一个视频卡，dou是一个包含了复杂DOM树、状态机、播放器的真实组件。Ru果放任不管，十几个播放器同时驻留内存，浏览器会直接崩溃。

为了兜住这层底线，我们在架构上设计了两大“降落伞”：

1. 双视图自由切换模式与CardPlayer实例池：

我们引入了NORMAL和ADVANCED两种模式。NORMAL模式下只展示普通小卡，仅显示封面和元信息，不播放视频，轻量且高效；ADVANCED模式下点击后直接展开内嵌播放器，通过改变card_style属性无缝切换，受CardPlayer管理器控制。这种按需加载的策略，极大地节省了内存资源。

2. 批量验证与共享缓存：

Ru果用户一次性粘贴10个链接怎么办？发10个API请求？服务器会报警的！我们重构了链接解析层，引入了批量验证和共享缓存。我们不仅支持从“链接”变“卡片”，还支持完美的逆向转换。通过resource_url字段保存用户原始输入信息，确保数据100%完整。

数据治理：Opus协议与历史兼容

新架构固然强大，但对于一个拥有海量存量数据的平台来说绝不Neng以牺牲历史数据为代价。同时新编辑器生产的内容也必须完美融入现有的内容分发基建。为此，我们围绕Opus协议设计了一套向下兼容历史、向上打通分发的全局策略。

Opus是我们内部定义的图文统一发布协议。为了无缝接入现有的动态分发渠道，确保高质量图文Neng够高效流转，新版编辑器在Zui终发布时会将所有文档树数据全量转换为Opus格式。这不仅统一了底层标准，也让生产端到分发端的链路彻底打通。

针对过去沉淀的千万级历史专栏，我们Yi经在服务端优先尝试将其向Opus格式进行转出与迁移。由于Opus是我们的标准协议，当这些转换成功的数据进入新版编辑器时Neng够通过Schema的精准映射，无损还原为内部的Document Tree，让老文章直接享受Zui纯粹的组件化编辑体验。

然而总有一些极其古老且无法安全迁移为Opus格式的富文本黑盒。面对这些“硬骨头”，我们并没有采用高风险的“强洗数据”，而是让新版编辑器利用加载H5内容的方式进行动态兜底。通过触发节点中预设的parseHTML规则，在浏览器端实时将陈旧的HTML代码“翻译”成全新的规范化Block Node，确保再老的专栏也Neng在新编辑器中顺利“复活”并进行二次编辑。

文档即应用

这场从“伪造”到“真实”的革命，不仅是一次技术栈的迁移，geng是一次对技术债的降维打击。通过这次架构升级，我们将“插卡”这一高频操作的体验提升到了新的维度。但在亮眼的数据背后我们也完成了一次经典的工程性Neng博弈。

文档不再只是静态内容的载体，而是动态应用的容器。我们终于Ke以说：在B站的专栏编辑器里你kan到的，就是真实的🎉。至于那些还在抱怨“kan视频卡”的用户，或许除了建议他们清理缓存、geng换浏览器或检查CPU性Neng之外我们还Ke以自豪地告诉他们：在创作端，我们Yi经消灭了那种“卡顿”。

-End-

---