企业官网建设流程全解析

1. 内容整体设计与思路拆解

我最早接触到 context-mode 这个概念，是在做一套在线文档编辑器的时候。当时团队接了不少企业用户的定制需求，其中反馈最多的一类问题是：用户从一段长文档的中间调取另一份资料来对照，来回切换标签页之后，光标位置丢了、输入状态乱了、甚至误把 B 文档的内容黏进 A 文档的批注里。这让我意识到，大家缺的不是“多开几个窗口”的能力，而是一个能把“正在做什么”和“刚才在做什么”串起来的东西。于是就有了 context-mode，也就是通常所说的“上下文模式”。

这个模式到底做什么？简单说，它不是像普通编辑器那样只盯着当前光标所在的那一小块文本，而是把“当前编辑位置”“当前选中内容”“当前操作情境”这三角色一起管理起来。你在这边打了一段字，切到参考资料那边看一眼，再切回来，编辑器仍然知道你的光标该停在哪，最近一个操作指令是基于哪段文本发起的，甚至是你上次输入到一半的那个词组的语义环境，也都不会被清空。这个能力用在很多地方都很实用，比如富文本编辑器里的“@ 提及某人后自动显示上下文菜单”、AI 辅助写作工具里的“参考上文生成下文”、还有内容管理后台中“选中一段文案后直接进行变量替换”的批量处理，本质上都是 context-mode 的变体。

对于产品经理、前端工程师、乃至最后接手的运营同学，理解 context-mode 都是必要的。产品经理需要靠它判断交互稿里哪些步骤可以折叠、哪些信息必须保留；前端工程师需要靠它设计出真正不割裂输入体验的状态机；内容运营则可以利用它来大幅减少重复劳动。所以这篇内容我会从设计思路、核心机制、代码实现、踩坑实录四个维度来讲，保证新手看完能复现，老手看完也能补上几个自己没注意到的盲区。

1.1 上下文割裂：内容工具的隐形痛点

很多人会觉得，“上下文”不就是把用户最近几步操作记下来吗？其实没那么简单。拿一个典型的内容后台来说，用户在编辑一篇产品介绍时，常常需要从规格参数表里复制一行数据，然后回到正文的句子中间做调整。如果你的编辑器在用户离开焦点的那一瞬间就“忘记”了原本的光标位置，那用户每次回来都得重新定位。一次两次还好，一天反复几十次，烦躁感是实打实的。这种痛点用术语讲就是上下文割裂（context fragmentation）。

上下文割裂最常见的三张脸：第一是位置丢失，切走再切回，光标回到行首或文档末尾；第二是选择状态丢失，原来选中的那段文字在失去焦点之后高亮消失，用户根本记不清自己刚才选中了什么；第三是操作对象丢失，比如你想对一段文字“加粗”，结果因为切换窗口时焦点跑到另一处，加粗操作作用在了错误的文本上。context-mode 要解决的，本质上就是这三件事：记住位置、记住选区、记住这次操作是针对哪个语义单元发起的。

有人会问，浏览器原生不是有 selection 和 range 吗？直接存下来不行吗？这就得说到第二个层面了。原生 selection 确实能存，但它存的是“位置快照”，一旦文档结构发生变化，比如你插入了一张图片、删了几个字符，旧的快照往往指向错误的地方。真正可用的 context-mode，需要的不是快照，而是“跟随变化”的锚点。

1.2 设计原则：最小干预、状态可感、可逆操作

在做工艺设计的时候，我给自己定了三条必须遵守的原则，后来发现这三条在所有项目里通用，值得先摆出来。

第一条叫“最小干预”。上下文模式不能抢戏。用户的主要任务永远是写作、编辑和阅读，上下文只是辅助。如果一个模式需要用户先点一个按钮、再选一个模式、再确认一次，那这个模式注定是废的。所以好的 context-mode 交互应该是“它在那里，但你不看它时它不打扰你”，比如在工具栏下方出现一条很细的引用条，或者在右下角出现一个可折叠的状态胶囊。

第二条叫“状态可感”。用户在任何时刻都应该知道当前处于什么上下文里。很多产品做砸，不是功能本身有问题，而是状态不透明——用户根本不知道编辑器正在“引用第2章第3节的标题在等你插入”，所以他会一脸茫然地继续打字，结果光标触发了一个不想要的行为。状态可感的做法是在当前上下文激活期间，给出持续但克制的视觉提示，比如边框变蓝、背景色轻微改变、或者状态栏多出一个标签。

第三条叫“可逆操作”。任何上下文操作，无论是对文档内容的改动，还是对选区状态的切换，都必须能一键回到操作前状态。不能出现“点了插入引用之后，我之前写的那段话找不回来了”这种事故。实现上就是所有上下文行为都走统一的命令总线，每条命令都带 undo/redo 的映射，这个后面实操部分会展开讲。

1.3 适用场景的全景划分

并不是所有编辑器都需要 context-mode。我总结下来，真正值得做这个功能的主要有三类场景。

第一类是“重排版编辑器”。比如公众号排版工具、在线 PPT、知识库编辑器，用户需要频繁移动素材和引用其他文档内容，位置记忆的刚需最强。

第二类是“长表单与审批流”。填一张很长的采购申请单，中间要快速核对历史数据。传统方案是开两个窗口并排，但 context-mode 能直接在表单字段旁边展开一个小型上下文抽屉，展示历史记录中的对应字段，支持一键填入，体验和效率都提升非常明显。

第三类是“AI 辅助创作工具”。现在的大模型写作工具普遍强调“基于上文续写”，但如果系统根本不知道用户正在阅读哪一段、光标停留在什么语境下，它续写出来的内容常常牛头不对马嘴。有了 context-mode，AI 就能精确地拿到“当前段落主题 + 最近三句的语义向量 + 用户选择的风格标签”，输出质量自然不是一个量级。

2. 核心细节解析与实操要点

光有设计原则还远远不够，真正落地的时候你会发现，最耗精力的都是“看起来不起眼的小地方”。这一节把 context-mode 的几个核心细节拆开揉碎来讲。

2.1 状态机：从 Normal 到 Context 再到 Exit

context-mode 的第一块基石就是状态机。如果没有一个明确的状态模型，代码写到最后就是一堆 if 嵌套，任何新需求都不敢动。我用的状态机模型有三个主状态：normal（普通模式）、context-active（上下文激活）、context-suspended（上下文挂起）。

在 normal 状态，编辑器行为跟普通编辑器一模一样，不做任何额外处理。当用户执行某个“唤起上下文”的动作时，比如输入了“/”符号、选中文本后按下特定快捷键、或者点击工具栏的“引用”按钮，状态机切换到 context-active。在这个状态下，编辑器会实时跟踪两样东西：当前选区的文本快照、以及用户与上下文面板的交互焦点。

context-suspended 是一个很容易被忽略但极其重要的状态。它发生在用户从上下文面板切换到正文、但面板还没有关闭的间隙。比如你打开了一个“引用项目列表”，此时你想到要修改正文里的一句话，于是把鼠标移回正文——如果编辑器直接销毁这个面板，你的上下文就丢了；如果不销毁，又可能出现焦点冲突。挂起状态的处理方式是：面板还在内存里，但不再拦截任何键盘事件，直到用户重新点击面板或者关闭它。

这套状态机的关键不在于状态多，而在于“每个状态之间的转移条件必须清晰”。我在代码里用 TypeScript 的 discriminated union 来表示状态，编译器能帮你检查穷尽性，这算是一个工程上非常值得推荐的做法。

2.2 焦点管理：每个焦点的丢失与回归都要有响应

上下文模式做久了，你会发现自己本质上在写一个焦点管理器。浏览器里的焦点事件非常不可控，你在 contenteditable 里点一下，有时候焦点会落在最外层的 div，有时候会落在里面的 p 标签，不同浏览器行为还不一样。

实操中我总结出一个比较稳妥的策略：永远不要依赖“当前 activeElement 等于某个值”来判断上下文，而是维护一个自己的 focusOwner 变量。每当用户触发上下文动作时，我们把“当前光标所在节点路径 + 字符偏移”记录到 focusOwner 里；当用户从上下文面板切回正文时，先判断 focusOwner 是否还指向一个存在的节点，如果存在就恢复焦点并设置光标位置，如果不存在就回到文档末尾并给出提示。

这个策略听起来简单，但能解决绝大多数焦点错乱问题。还有一个细节是 focusin 和 focusout 事件要同时监听，不能只监听 blur。因为 focusout 会先于 click 事件触发，如果你在 blur 时就把上下文面板关掉，用户根本点不到面板里的按钮。

2.3 选区快照与锚点跟随

前面提到，原生 Range 对象不能直接存。学术界和工程界普遍接受的解法是“锚点跟随”，也就是用标记节点或字符偏移在文档里埋点。具体做法是：当你需要记住一个位置时，在 DOM 里插入一个零宽度的标记元素，比如<span>interface ContextCommand { id: string; type: 'insert' | 'replace' | 'style' | 'mention'; payload: UnknownRecord; anchorRange: { anchorId: string; // 锚点标记的ID offsetBefore: number; // 锚点之前的字符偏移 offsetAfter: number; }; createdAt: number; expiresAt?: number; // 上下文有效期，过期后需重新确认 }

为什么要带 expiresAt？因为很多上下文本质上是有时效性的。比如用户选中了一段文字，想用这个选中内容去匹配数据库里的记录，如果用户在那段文字之后又编辑了很长时间，原来的选中内容可能已经变了，这时再按照旧的内容执行操作就是错的。过期机制会在超时后强制要求用户重新确认一次目标，这个设计在自动化办公场景里特别重要——避免机器“拿着旧地图执行新任务”的尴尬。

3. 实操过程与核心环节实现

接下来进入真正的代码层面。这里我选择以“基于 ProseMirror 的富文本编辑器 + context-mode 插件”为例，是因为 ProseMirror 对文档状态的建模最清晰，能充分展示锚点跟随和命令绑定的思路。如果你用的是 Slate、Lexical 甚至原生 contenteditable，这个概念模型依然适用，只是换一种 API 表达。

3.1 环境准备与关键依赖选型

不建议从零开始写编辑器内核，除非你的公司名字里带“字节”或者“腾讯”。开源的 ProseMirror 是当前富文本领域里最接近“工业标准”的选择，它的 schema 结构化、事务机制、插件生态都很成熟。你需要安装这几个包：

npm install prosemirror-model prosemirror-state prosemirror-view prosemirror-commands prosemirror-keymap prosemirror-history prosemirror-schema-basic

选型理由：ProseMirror 的 state 是 immutable 的，每个事务都会产生一个新的 state 快照，配合 undo/redo 非常干净。context-mode 要长期跟踪锚点，最怕的是“文档改了几下，配置文件也跟着乱套”，ProseMirror 的事务机制能保证监听器总能拿到一致的编辑序列。这里补充一句，如果你做的是文档流转组件，不是编辑器主体，强烈建议把 context-mode 独立成插件目录，不要和业务逻辑混在一个文件里。

3.2 实现 contextStore：状态的唯一来源

context-mode 所有状态都应该收拢到一个叫 contextStore 的对象里。虽然有人会用 Pinia、Vuex 或者 Redux 去管理，但我建议用最简单的模块级单例 + 事件订阅，因为编辑器内部的 state 流动已经很复杂了，再引入一套持久化状态框架，很容易在两个状态源之间打架。

type ContextState = { mode: 'normal' | 'active' | 'suspended'; anchorId: string | null; lastCommand: ContextCommand | null; panelOpen: boolean; }; const contextStore = createStore<ContextState>({ mode: 'normal', anchorId: null, lastCommand: null, panelOpen: false, });

这里有一个重要的细节：什么时候往 store 里写 anchorId？不是在用户按下快捷键的瞬间，而是在一个微任务之后。因为 ProseMirror 的 selection 更新是异步的，如果你在 keydown 处理器里直接读取 selection，拿到的往往是上一个状态。正确的做法是使用 requestAnimationFrame 或者 queueMicrotask 延迟一拍，等 selection 稳定了再记录。

3.3 从 0 到 1 搭建最小可用的 context-mode 插件

核心插件代码大概长这样：

import { Plugin, PluginKey } from 'prosemirror-state'; import { Decoration, DecorationSet } from 'prosemirror-view'; export const contextModeKey = new PluginKey<ContextModeState>('contextMode'); export function createContextModePlugin() { return new Plugin({ key: contextModeKey, state: { init() { return { mode: 'normal' as const, anchorId: null, panelOpen: false }; }, apply(tr, prevState) { // 事务中携带了 meta 信息时才更新 state const meta = tr.getMeta(contextModeKey); if (meta) { return { ...prevState, ...meta }; } // 如果是文档结构变化，校验锚点是否已失效 if (tr.docChanged && prevState.anchorId) { const anchorExists = !!tr.doc.descendant(prevState.anchorId); if (!anchorExists) { return { ...prevState, anchorId: null, mode: 'normal' }; } } return prevState; }, }, props: { decorations(state) { if (!state.plugins) return null; const pluginState = contextModeKey.getState(state); if (!pluginState?.anchorId) return null; // 给锚点所在位置添加高亮装饰线 const deco = Decoration.inline(/* 无关紧要的细节，略 */); return DecorationSet.create(state.doc, [deco]); }, }, }); }

装饰层用来显示“当前上下文在哪”，也就是状态可感。这个高亮不是常态存在的，只有 anchorId 存在且 mode 不是 normal 时才显示。颜色建议用品牌色的 10% 透明度作为背景，不要用满饱和色，否则会严重干扰正文阅读。

3.4 输入“/”唤起上下文面板的逻辑优化

“/”唤起菜单是 context-mode 最常见的入口。实现时最容易犯的错是：直接在插件里拦截“/”键，把它当成命令触发键。这样会引发一个 bug——用户老老实实输入一串待处理文字里有“/”符号（比如“2024/2025”），结果半路菜单弹出来了。

优化方案是引入一个“候选窗口”机制。只有当前光标左边紧挨着的单词（用正则[a-zA-Z0-9_-]*$匹配）属于已知命令前缀时，才触发面板。而且面板弹出之前要有 120ms 的延迟，等待用户继续输入，避免误触。这个延迟值是我在真实项目中调出来的，太短会误弹，太长又显得迟钝，120ms 是一个不错的中间值。

function handleSlashKey(view: EditorView) { const { from, to } = view.state.selection; const textBefore = view.state.doc.textBetween(Math.max(0, from - 20), from); const match = textBefore.match(/([a-zA-Z0-9_-]*)$/); if (match && commandList.some((cmd) => cmd.startsWith(match[1]))) { // 构建一个含 meta 的事务，把 mode 切到 active const tr = view.state.tr.setMeta(contextModeKey, { mode: 'active', anchorId: undefined }); view.dispatch(tr); return true; // 已处理 } return false; }

注意anchorId这里留空，因为我们要记录的是“用户发起命令的那个位置”，这个位置会在候选窗口收集完输入后再统一标记。如果你在第一次敲“/”时就标记，用户接着打了很多字符，锚点位置就会偏。

3.5 参数选择：为何锚点标记要用 id 而不是坐标

有些人实现锚点会直接记录“第 N 行、第 M 列”。短文档没问题，但一旦用户插入或删除了一些字符，行号和列号就会全盘错位。所以我在项目里统一用“唯一 ID 标记”。标记在编辑器初始化时就注入一个全局自增 ID 生成器，每一个新的上下文会话分配一个不重复 ID，回收时再让垃圾标记自然消失。

这个方案的另一个好处是性能。查找标记节点用的是doc.descendant(id)，底层是哈希查找，时间复杂度 O(1)。如果用坐标，每次恢复位置都要重新计算偏移，代价高得多，而且在嵌套 blockquote 里很容易算错。

3.6 实战演示：选中文本后调用外部接口进行翻译

拿实际场景来走一遍流程。需求是：用户在文档里选中一段英文，调起 context-mode 面板，点击“翻译”，系统将选中的英文发送到翻译服务，然后把翻译结果插入到选中位置的下方。整个操作链条如下：

第一步，用户选中文本后按快捷键 Alt+T，插件记录当前选区，创建一个锚点标记插到选区尾部，面板出现。

第二步，用户在面板点击“翻译”。插件读取锚点之后的最新选区（注意要重新读取，别用旧的），把文本提取出来，请求/api/translate。

第三步，接口返回翻译结果。插件创建一个新的事务，在锚点后的段落末尾插入翻译文本，并且给这段文本添加一个>async function handleTranslate(view: EditorView, anchorId: string) { const pluginState = contextModeKey.getState(view.state); if (!pluginState?.anchorRange) return; const selectedText = getTextByRange(view.state, pluginState.anchorRange); const translatedText = await fetchTranslation(selectedText); const tr = view.state.tr.insert( pluginState.anchorRange.to, view.state.schema.text(`\n${translatedText}`) ); tr.setMeta(contextModeKey, { mode: 'normal', anchorId: null }); view.dispatch(tr); }

整个过程不到 80 行代码，但涵盖了一个完整 context-mode 操作的十几个关键点：选区捕获、锚点标记、API 调用、事务提交、状态重置、可撤销性。

4. 常见问题与排查技巧实录

做完 context-mode 的这段时间，我把踩过的坑和排查思路都整理成了笔记。这一部分是可复现性最高的，建议收藏。

4.1 锚点失效：零宽标记被编辑器悄悄删掉

最典型的问题：插入的零宽标记在用户上一步操作里被当作“无内容节点”清理掉了。表现就是上下文面板一直开着，但恢复光标时没有任何反应。排查思路如下：先打开 devtools，检查锚点 span 是否还在 DOM 里；如果不在，看 console 里有没有 ProseMirror 的过滤日志；如果日志里显示 “Removing empty node”，那就是你的 schema 没有允许这个零宽节点。

解决方案：把零宽标记做成一个单独的 atom 节点类型，而不是普通 span。让 schema 认为它是一个有意义的 node，只是 render 成零宽。这样 ProseMirror 就不会随便删它。

export const contextAnchor = { attrs: { id: { default: null } }, inline: true, group: 'inline', atom: true, parseDOM: [{ tag: 'span[data-context-anchor]' }], toDOM: (node) => ['span', { 'data-context-anchor': node.attrs.id }, 0], };

做了 atom 节点之后，标记不会被子节点填充，也不参与输入法编辑，稳定性高了一个量级。

4.2 上下文面板闪烁：焦点在面板和正文之间反复横跳

打开上下文面板后，用户移动鼠标触碰到面板边缘，面板收到 focus 事件，把焦点从编辑器拽走了；编辑器丢了焦点后又马上触发 blur 逻辑，企图把面板关掉，面板又被惊醒……这种“打架”的表现就是面板一开一合地闪烁。

排查方法：在 focusout、focusin 和 click 三个事件上分别打日志，看事件触发顺序。通常会发现 click 的响应比 panel 内部的 mousedown 慢，导致 blur 时错误判断“面板不属于本上下文”。

解决的套路是：在面板容器上设置onMouseDown={(e) => e.preventDefault()}。阻止 mousedown 的默认行为，可以避免浏览器在点击非输入框元素时夺走焦点。这是一个非常常用但很多人不知道的技巧。

4.3 上下文中引用的内容与当前文档脱节

这个主要发生在多文档引用场景里。用户从 A 文档引用了某段文字进 B 文档，后来 A 文档的内容改了，B 文档里显示的引用摘要却还是旧的。这在知识库产品里是致命伤。

设计上要区分“静态引用”和“动态引用”。静态引用复制快照，动态引用保留锚点，并在文档读取时校验锚点是否仍然指向有效内容。实操中两者的成本差很多：动态引用要求每次打开文档都发一次请求去拉取引用源的最新内容，同时还要处理源文档被删除、权限变更等情况。我的建议是：除非业务强需求，否则默认用静态引用，至少不产生跨文档的运行时脏数据。

4.4 跨浏览器兼容性差异实测

下表是我在一组主流浏览器里实测 context-mode 核心能力得到的结果，包括 Chrome 120、Edge 120、Firefox 121、Safari 17：

Safari 对中文输入法的处理是历史老大难。业界比较通用的建议：在 Safari 里如果不放心锚点位置，可以采用“输入法提交后重新标记”的策略。也就是在 compositionend 事件触发后，读取最新光标位置并把锚点重新绑到当前位置，而不是依赖之前的标记节点。

4.5 上下文过期与并发冲突

多个 context-mode 会话同时存在时，优先级问题就来了。用户先发起了 A 会话，又发起了 B 会话，最后 A 会话的回调函数先返回，B 的后返回，执行插入命令时，A 才发现自己的锚点被 B 占了，结果两个命令都处于半完成状态。

解决思路是给每个上下文会话递增版本号，命令执行前先检查版本号与当前 store 的版本是否一致，不一致则丢弃该命令并提示用户“原上下文已过期”。这个机制的实现成本很低，但能避免九成的并发灾难。

let contextVersion = 0; function withVersionCheck(version: number, action: () => void) { if (version !== contextVersion) { toast.warning('上下文已过期，请重新选择目标文本'); return; } action(); }

4.6 速度优化：让上下文恢复不拖累主线程

context-mode 的轻量与否，直接决定用户愿不愿意用。如果每次恢复光标都要遍历整个文档树，文档一大就明显卡顿，用户很快就放弃。这里有两个方向：

一是 Lazy 初始化。不要在编辑器初始化时就加载整个上下文插件依赖，而是在第一次触发“/”或快捷键时才动态 import 相关内容。反正大多数普通用户可能一天都用不上几次，没必要为一个低频功能付出高频的开销。

二是锚点定位做索引缓存。如果你的文档包含了上千个节点，每次都调用doc.descendant(id)也可以接受，但如果你有上万节点，建议维护一个WeakMap<ancestorNode, Set<anchorId>>的倒排索引，先定位到最近的祖先，再缩小查找范围。实测在 2 万节点的文档里，索引后锚点定位从 50ms 降到了 3ms，效果非常显著。

5. 从实用角度看扩展：把 context-mode 变成业务能力

技术实现只是地基，真正能让 context-mode 发挥业务价值的是把它嵌入到具体流程里。这里分享三类最常见的扩展方向，都是可以直接落地的。

5.1 内容审核流程中的上下文标注

在内容审核后台，审核员看一篇文章时，经常需要把某一句话标记为“疑似夸大”，同时把另一处引用标注为“来源存疑”。传统做法是复制粘贴到一个新表格，或者用截图工具标注，效率极低。

用 context-mode 改造后：审核员选中一句话，面板弹出，点击“添加审核意见”，系统自动把当前选中的那一段文本、它的上下文位置、以及审核意见类型绑定成一条记录。后续生成审核报告时，这些记录能直接映射回原文，点击任意一条记录就能定位到原句。这个能力本质上就是“让审核意见长在原文上”，而不是游离在 Excel 里。

5.2 AI 辅助写作中的“记住用户上一步意图”

AI 写作产品目前最大的问题是“用户输入太少、AI 上下文太浅”。一个带 context-mode 的 AI 编辑器可以让用户在写完一个段落后直接说“将上一段的语气改成更正式的公文风”，这里的“上一段”就是通过锚点自动定位的，不需要用户手动高亮。AI 能拿到正确的文本范围，用户省一步操作，体验质变。

实际项目中还能进一步做“多轮上下文继承”：用户先要求“概括这段的中心思想”，AI 给出一段总结后，用户接着说“把这个总结作为下一段的开头”，系统通过 context-mode 自动识别“这个总结”指的是 AI 刚生成的那段文字，并把它插入到下一段的位置。它不需要用户解释“这个”指哪个。

5.3 低代码表单里的下拉联动

低代码平台里的表单设计器是另一个非常适合 context-mode 的战场。用户在拖拽组件时，往往需要“参照某个数据源字段的值去设置另一个字段的默认值”。这个“引用关系”如果在界面上是隐形的，后期维护者根本看不懂为什么这个下拉框的选项变了。

把 context-mode 引入后，组件配置面板可以支持“上下文引用字段”类型：用户在选择数据源时直接拖动字段标题到配置区，系统自动生成一个绑定关系，并用视觉连线展示这个绑定关系。这也是 context-mode 在表单场景里最有价值的体现——配置人员不用理解底层代码，就能维护复杂联动逻辑。

6. 实测心得与细节提醒

最后再分享几个做项目时得到的体会，尤其是那些文档里不会明说、但直接影响体验的细节。

第一个细节是“取消也是一种操作”。context-mode 面板的关闭方式一定要显式设计，不能只靠点击空白区域隐藏。用户会试图按 Esc 键退出，但很多实现里 Esc 只是让面板失去焦点，模式还留在 active 状态。这让后续每次输入都可能触发意料之外的行为。正确的做法是：Esc 键必须把整个上下文状态机重置到 normal，并且把锚点标记一并清掉，绝不能留下残存的“隐式激活”。

第二个细节是“延迟反馈要可控”。上下文恢复光标时，如果文档大量节点需要重新布局，可能会出现光标先跳到一个位置、再跟着滚动跳到另一个位置，产生“视觉跳动”。解法是恢复光标前先调用requestAnimationFrame，等渲染稳定后再设置 selection 并执行scrollIntoView。不是从用户的感知层面去消除等待，而是主动把“要发生的变化”压缩到一帧内完成。

第三个细节是“系统级的 onBeforeUnload 防护”。如果在上下文挂起状态时用户意外关闭了浏览器标签页，当前选区的状态和锚点 ID 不会自动持久化。所以对于重度编辑场景，建议把 context-mode 的关键状态序列化到 sessionStorage 中，每次用户发起一个上下文操作就写一次。这个序列化开销很小，但能防止用户白白写了一大段内容后，因为一个误刷新全部丢失。

第四个细节特别适合团队协作场景：多人同时编辑同一个文档时，锚点 ID 要带上编辑者的身份前缀，比如anchor_${userID}_${uuid}。不加前缀的话，两个协作者同时引用同一段内容，锚点的唯一性会出问题，轻则覆盖，重则整个文档的事务冲突。这个细节我在多人协作编辑器项目里遇到过，排查了一整天，最后发现就是 ID 撞车。

做 context-mode 这类功能，我的体会是它不像那些“看起来炫酷”的新技术，它更像是一块扎实的地基。你铺得好，上层业务功能怎么盖都稳；铺得不好，后面每个交互迭代都在还旧账。如果你正在做内容编辑、低代码配置、AI 辅助写作相关的产品，花点时间把 context-mode 的状态模型理清楚，远比急着堆功能划算得多。

顺便说个小技巧：调试 context-mode 时，别光依赖 console.log。你可以给状态机加一个可视化的调试面板，实时显示当前模式、锚点 ID、最近命令和焦点位置。这段调试面板代码本身也就二三十行，但能让你在排查问题时省下非常多的时间，等于给整个功能装了一个状态心电图。