把输入框变成 AI 的“超级入口”（ProseMirror 全流程实战）

📌 一句话摘要

本文以知识库问答输入框的 @文档 功能为案例，详细讲解了从 DOM 方案踩坑到转向 ProseMirror 架构的全流程实战，包括 Schema 定义、Decoration 临时态处理与 Suggestion 插件实现。

📝 详细摘要

文章记录了在知识库问答输入框中实现 @文档 引用能力的完整技术历程。作者最初尝试基于 contenteditable 的 DOM 方案，但在处理文本与原子节点混排时遇到光标定位不稳定、输入法打断、撤销栈污染等痛点，最终转向 ProseMirror 框架。文章详细介绍了 ProseMirror 的核心架构（不可变文档、事务、状态、视图），并围绕 @文档 需求给出了具体的 Schema 定义（text、docref、hard_break 三类节点）、Decoration 实现（用于查询高亮等临时渲染态，不污染文档结构）以及基于 Suggestion 插件的完整交互流程（触发、匹配、显示、确认、插入）。文章强调通过结构化治理而非经验修补来保证编辑器稳定性，对实现类似富文本引用功能的开发者有直接参考价值。

💡 主要观点

- 基于 contenteditable 的 DOM 方案在处理混排内容时存在多个稳定性痛点。 光标在嵌套节点中难以稳定恢复、输入法组合输入期间修改 DOM 易出错、用 innerHTML 纠正结构会污染撤销重做栈、临时交互态混入文档后难以维护，这些是转向 ProseMirror 的直接原因。

ProseMirror 的 Schema 机制将文档结构定义与渲染解耦，是稳定性的基础。 通过定义 text、docref（原子行内引用节点）、hard_break 三类节点及其 toDOM/parseDOM 规则，编辑器能精确控制文档的组成与序列化，避免 DOM 方案中的结构混乱。

Decoration 是处理临时渲染态（如查询高亮）的正确方式，不污染文档结构。 @ 后的查询高亮块是临时状态，最终会被选中的 mention 替换。使用 Decoration 而非写入文档，可以避免中间态压入历史栈，保证撤销/重做行为的可预期性。

Suggestion 插件封装了触发、匹配、显示、确认的完整交互链路。 基于 ProseMirror Plugin 实现的 Suggestion 机制，在每次事务 apply 时匹配触发串（@），通过 Decoration 显示高亮，并通过渲染层的回调完成候选选择与 docref 节点插入，将交互逻辑控制在事务边界内。

💬 文章金句

- 当编辑器里开始出现「文本 + 原子节点」混排时，复杂度会从「能不能插进去」转移到「能不能一直稳定」。

• 把问题讲清楚、把边界拆清楚，编辑器能力才有机会长期演进。
• 这次踩坑之后，我才真正理解 ProseMirror 的价值。

📊 文章信息

AI 初评：86

来源：vivo互联网技术

作者：vivo互联网技术

分类：软件编程

语言：中文

阅读时间：13 分钟

字数：3057

标签： 前端与 Web, 富文本编辑器, ProseMirror, AI 产品与应用, 工程实践

阅读完整文章