企业官网建设流程全解析

如果你在编辑器里选中一段文字后，旁边会自动浮出“加粗、引用、复制”这一组操作；而在聊天窗口里长按一条消息，弹出来的却是“复制、转发、撤回”另一个菜单——你正在体验的，就是 context-mode。

我最初接触这个概念，是在做某个模拟项目时。当时产品经理提了一个需求：同一个按钮，在不同的场景下要有不同的行为。我一开始以为这只是改几个条件分支的事，后来越改越发现，改的不是按钮，而是整个应用需要根据“用户当下正在做什么”来切换自身的语言、功能分布和信息层级。这篇文章就聊聊我在实际工作中对 context-mode 的理解、拆解和落地经验，适合正在做交互设计、前端开发，或者正在为“界面太乱”发愁的同行参考。

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

1.1 先给 context-mode 一个能落地的定义

我给 context-mode 的定义是：一套以“当前上下文”为核心驱动力的界面与逻辑组织方式。系统不再把所有能力摊开铺在界面上，而是根据用户当时所处的页面、操作行为和推测出来的意图，动态调整可见功能、展现形式和交互优先级。

这个概念用一个生活化的类比解释特别清楚：你手里拎着一个工具箱，蹲下来拧螺丝的时候，工具箱自动打开一格，里面只有螺丝刀；等你站到墙边准备刷漆，它又自动换了一层，里面是滚刷和砂纸。它没有把所有工具一起倒在地上让你挑，而是基于你的姿势、位置和目标，只提供最可能用到的那几样。这带来的好处很直接：用户省去了寻找和判断的时间，手滑误点的概率也会降低。

在实际项目里，一个典型的 context-mode 甚至不一定能被人一眼看出来。比如表单里某个字段值校验失败，页面并没有弹出一个全局错误框，而是把那个字段标红，同时底部保存按钮换成了“定位到错误”，并自动把滚动条挪到出错的字段附近。这个瞬间，整个界面的“焦点”和“行为”都根据“校验失败”这个上下文发生了变化，这就是一次成功的 context-mode 应用。

1.2 为什么要做 context-mode：信息过载与认知负担

传统界面设计的思路是“把所有功能尽量暴露出来”，用户自己去找自己需要的东西。这种方式在功能数量少的早期产品里很有效，因为随便翻翻就能找到；但功能一旦多起来，界面就会变成“菜单深海”和“功能迷宫”。我见过一个内部业务系统，导航里挂了上百个功能入口，但通过对操作日志的统计，用户每周真正点击过的功能只有十来个，其余绝大多数入口都是噪音。

context-mode 就是为了解决这个矛盾：它不是把按钮临时排序变一变，而是重新组织整个界面的信息层级。普通“智能菜单”只是在保留所有入口的前提下，把高频项往前排；而 context-mode 会把与当前上下文无关的入口折叠起来，甚至暂时隐藏“在其他模式里很重要、但当前场景里只会干扰用户操作”的功能。

这种设计跟人的认知模式是匹配的。人在专注做一件事时，注意力范围会收窄，界面里无关信息越多，越容易打断心流、增加决策时间。让界面“跟着上下文走”，本质上是在帮用户过滤噪音。所以我会把 context-mode 看作是产品从“功能导向”转向“任务导向”的一个关键设计手段。

1.3 方案选型：规则驱动还是状态驱动？

第一次做 context-mode 的团队，绝大多数会从“规则驱动”入手。所谓规则驱动，就是写一堆 if/else 硬判断：如果当前页面是订单详情页、并且用户选中了商品列表中的某一行、并且这个订单还没有发货，那就显示“取消订单”按钮。这套方案很直白，也很好理解，但规则一旦多起来，就会互相打架。我见过最头疼的情况是，两条规则同时满足时会做相反的操作，最后只能靠再补一条优先级规则来救火，规则之间形成了一张剪不断理还乱的关系网。

另一条路线是“状态驱动”。它不直接描述“什么情况下显示什么”，而是先把用户操作沉淀成可计算的上下文状态：用户正处于流程的哪一步、正在编辑什么对象、有没有未保存的修改、最近连续做了哪三个动作。之后再写一个“状态到模式”的转换函数，由当前状态决定模式，再根据模式渲染界面。

从我的经验来看，最好是这样走：启动验证阶段用规则驱动，因为需求还不稳定，随时要调整，写规则最快；当规则超过十几条、冲突开始出现时，果断重构到状态驱动。状态驱动的最大优势在于可测试性，因为“状态到模式”的转换可以抽成纯函数，把各种栈结构输入进去，直接断言输出是什么模式，比在真实界面里反复点按钮验证可靠得多。两种方式的取舍，本质上是短期开发效率和长期维护成本的博弈。

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

2.1 上下文识别的三种粒度：页面、行为、意图

context-mode 的第一步，也是最核心的一步，是“识别上下文”。我一般会把它分成三个粒度，分别对应不同的实现成本和产品效果。

第一层是页面级上下文。这是最简单、最容易被感知的：用户进入“草稿箱”页面，界面自然进入草稿管理模式；进入“邮件阅读”页面，界面变成阅读排版模式。实现方式基本就是监听路由变化或页面加载事件。这一层适合解决“入口太多”的问题，几乎不需要复杂的算法，风险也最低。

第二层是行为级上下文。它不只看用户身在哪个页面，更看他刚刚做了什么。比如用户在一个数据表格里连续点击了三行单元格，我们判断他大概率在批量编辑，于是表格底部自动浮现“批量修改”工具栏；比如用户正在输入框里连续敲击，但光标位置没有落在表单内，而是落在页面的搜索区域，我们的界面就会把搜索建议放大，同时收起一些无关组件。这一层需要监听操作序列，并设置触发阈值，具体阈值选择我会在第三节详细展开。

第三层是意图级上下文，这是最进阶的做法。它在行为序列基础上结合历史规律，去推测用户最终想达成的目标。比如用户先打开了一个客户资料页，紧接着打开了报价单模板，系统猜测他可能是想给这个客户做一份报价，于是主动在侧边栏展示“最近给同类型客户报价的模板”。这一层难度最高，通常需要一定的数据沉淀和推荐逻辑，早期阶段不必强行做，把页面级和行为级做扎实，体验已经能比传统界面提升一大截。

2.2 上下文状态建模：一个可计算的上下文栈

实践中最容易踩的坑，是只用一个“当前上下文”变量来存储状态。用户的操作通常是嵌套深入、再逐层返回的，比如：进入草稿箱 → 打开一封邮件 → 选中邮件里的附件 → 点击附件旁边的“转发”按钮。这个流程里，上下文是逐层叠加的。如果只用单个变量保存“此时处于附件选中状态”，一旦用户按 Esc 退出附件选中，系统就不知道该回到“邮件编辑”模式还是“草稿列表”模式。

更好的建模方式是使用一个上下文栈（context stack）。栈底通常是页面级上下文，往上依次是面板级、对象级、选中级等更细粒度的上下文。栈顶元素决定当前模式，出栈时自动回到上一层，天然符合用户“一层层进入、再一层层退回”的操作直觉。

下面是一个通用的上下文数据结构示意：

const contextStack = [ { level: 'page', id: 'draft-list', meta: { pageTitle: '草稿箱' } }, { level: 'panel', id: 'mail-editor', meta: { mailId: 'mail-001' } }, { level: 'selection', id: 'attachment-selected', meta: { attachmentId: 'file-099' } } ];

在代码实现里，我们只需要保证三条规则：进入新的操作场景时压栈；完成当前场景或用户主动退出时弹栈；任何一次压栈或弹栈之后都要重新计算当前模式。这样做还有一个额外的好处：上下文栈本身是可序列化的，只要把它存下来，就能完整还原用户的操作路径。我在调试时经常把这个栈打印出来，比看几百行日志直观得多。

2.3 UI 切换节奏：不能让人察觉“混乱”

context-mode 的界面切换，是用户感受最直观的部分。切换得好，用户只会觉得“它懂我”；切换得糙，用户就会觉得界面在跳来跳去，像有人在背后乱点鼠标。我在实践中总结了三件必须做的事。

第一，内容区域要尽量保持稳定。模式切换时，如果整个页面重新渲染、滚动条跳回顶部，用户就会瞬间丢失位置感。正确做法是只替换与模式相关的工具栏、浮层和辅助面板，主内容区能不动就不动。第二，不能丢掉用户的输入焦点。假设用户正在搜索框里打字，系统因为某个行为判断要进入“筛选模式”，这时候如果搜索框被重新创建，光标就会消失，用户输入的半句话也可能会被清掉。这个问题非常常见，我会在后面的常见问题部分专门讲解决方案。第三，切换动画时长控制在 150ms 到 250ms 之间。太短会觉得生硬，太长会觉得拖沓，这个区间是试了很多次之后比较舒服的范围。

还有一个值得注意的细节：把“模式声明”和“模式渲染”分离。模式声明是计算当前应该处于什么模式，它应该是一个纯逻辑过程；模式渲染是根据模式去更新界面。这两个过程一旦混在一起，就会出现某个模式计算还没完成、渲染又触发了新的上下文事件，导致循环更新。我在架构上会用事件机制解耦，后面会给出一个最小实现。

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

3.1 最小闭环：选中文本就弹出的操作条

要理解一套模式，动手做一个最小闭环最有效。我建议从“编辑器内选中文字后弹出操作条”这个需求开始，因为它的上下文变化非常清晰：选中文字时进入“文本操作”上下文，光标移开或选中取消时退出。整个闭环只需要四步。

第一步，监听选区变化事件。选中范围发生变化时，我们拿到选区的位置，并判断选中的文字长度是否大于 0。第二步，提取上下文。根据选区的范围和页面内元素的位置，构造一个上下文对象，里面至少包括选中文本、选区坐标、当前编辑器容器 id。第三步，计算模式。把上下文丢进 resolver 函数，如果选中的是非空白文本，就返回 text-actions 模式；如果选区消失，就返回 none 模式。第四步，渲染反馈。根据模式，在选区附近浮出操作条，或把操作条隐藏。

这套最小闭环跑通之后，你会发现后续复杂的 context-mode 都只是把第二步里的上下文对象做得更丰富，把第三步里的 resolver 函数推理得更聪明，整体骨架并不会变。先把这个流程走顺，后面扩展才不容易失控。

3.2 一个可复制的 contextManager 核心实现

下面给出一个不依赖任何框架的轻量级 contextManager，它包含注册上下文、压栈弹栈、模式重算和模式回调四个核心能力。这段代码我在好几个项目里都改过，结构比较通用。

class ContextManager { constructor() { this.stack = []; this.mode = null; this.handlers = new Map(); this.resolver = null; } setResolver(resolverFn) { this.resolver = resolverFn; } registerMode(modeName, enterHandler) { this.handlers.set(modeName, enterHandler); } pushContext(context) { this.stack.push(context); this.recompute(); } popContext() { this.stack.pop(); this.recompute(); } recompute() { if (!this.resolver) return; const nextMode = this.resolver(this.stack); if (nextMode === this.mode) return; const handler = this.handlers.get(nextMode); if (handler) handler(nextMode, this.stack); this.mode = nextMode; } }

这里最关键的是 recompute 里的防御逻辑：只有新模式和当前模式不同时，才会真正执行切换。很多模式频繁抖动的场景，就是因为这里没做对比，导致每次状态更新都触发一次界面重建。另一个关键点是 resolver 最好写成纯函数：输入 context 栈，输出模式名。这样单元测试非常方便，我可以在测试里直接构造各种“栈结构+期望模式”的映射表，跑一次就能覆盖大量分支，而不需要真在浏览器里点来点去。

使用的时候，只需要初始化一个管理器，注册模式，然后不断根据用户事件压栈或弹栈。比如在编辑器里选中文字时，push 一个 selection 上下文；点击空白区域时，再把这个上下文 pop 掉。整个过程里，界面层完全不知道规则是什么，它只负责响应模式进入回调。

3.3 核心配置：阈值、超时与优先级

context-mode 能不能真正好用，往往不取决于架构，而取决于几个关键参数选得准不准。我把它们单独拿出来说，因为这几项直接决定用户会不会觉得模式“太灵敏”或者“太迟钝”。

第一项是行为级识别的阈值。以“连续点击三次表格行进入批量编辑”为例，阈值设为 2 的话，误触概率很高；用户本来只是想逐行浏览一下，结果不小心连续点了两行，就跳进了批量编辑模式。阈值设置为 3 或 4，感受会稳很多，但要牺牲一点点响应速度。我的建议是从 3 起步，再根据误触反馈调整。第二项是超时时间。上下文不能永远停留在栈里，用户超过一定时间没有操作，栈里的行为级上下文就应该自动降级，回到页面级模式。这个时间我一般取 1500ms 到 3000ms 之间，太短会导致用户多思考半秒就触发降级，太长则会让过期的上下文一直霸占着界面。第三项是优先级。多个上下文同时存在时，必须有一个裁决顺序。我比较用的优先级是：selection（选中） > focus（聚焦输入） > gesture（手势） > page（页面级）。这个顺序可以让临时性最强的操作（比如选中文字）盖过其他模式，因为选中的一个行为本身就标志着用户当前的意图最明确。

我把这些参数集中放在一个配置对象里，而不是散落在逻辑各处，后续调整时只需要改配置项，不需要动代码逻辑。

const config = { behaviorThreshold: 3, contextTimeout: 2000, priority: ['selection', 'focus', 'page'] };

用表格总结一下参数选择建议：

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

4.1 上下文抖动与切换死循环

我在实际调试中遇到最多的问题，就是“抖动”现象。外在表现是模式刚切过来，马上又切回去，或者两个模式不断交替出现，界面像霓虹灯一样闪。原因通常有两个：一是 resolver 里对上下文的判断不完整，同一个事件同时满足两个模式的进入条件，导致 recompute 反复横跳；二是上下文栈压入和弹出的时机撞在了一起，压栈操作触发了一次 recompute，紧接着弹栈又触发了一次。

解决办法也很直接。首先在 recompute 里对比 mode 是否变化，这能挡掉一部分无意义的重入。其次引入一个“模式稳定窗口”：每次切换完成后，在 200ms 内忽略新的切换请求。这个窗口不是硬编码在条件里的，而是用一个时间戳记录上次切换时间，如果当前时间距上次切换小于窗口值，就只更新 mode 标记，不执行渲染。最后，给 resolver 设置一个明确的优先级表，让“多个上下文同时满足”变成一个可预测的输出。

排查抖动时，我会用日志把每次 recompute 的触发原因记录下来，输出当前栈、输入上下文、输出模式和触发事件源。日志格式类似这样：

[recompute] stack=page>editor>selection, input=selection, output=text-actions, reason=selectionchange

然后我回放整个操作序列，观察到底是哪一步让两个模式互相抢占。绝大多数情况下，日志会比人眼盯着界面更早发现问题。

4.2 模式切换导致用户输入状态丢失

这个问题的典型场景是：用户正在一个输入框里填写内容，系统因为某些行为判断进入了另一个模式，然后界面重建，输入框里的文字和光标位置全部丢失。用户在浏览器里表现出的行为通常很愤怒，因为自己打的一段话突然没了。

这里要认清一个事实：输入框的文字、光标、滚动位置等状态，本质上也属于用户上下文的一部分。如果我把它们丢在组件内部，模式切换时组件一卸载，状态就灰飞烟灭。正确做法是把输入状态提升到上下文栈的 meta 中。也就是说，压栈时如果当前输入框有内容，就把 draft 文本和光标位置记录下来；模式切换后，如果同一输入框重新出现在界面上，再从 meta 里恢复。

还有一个实现层面的细节：模式切换如果只是临时让出界面空间，最好用“局部渲染”而不是“整体重建”。我通常会把界面拆成稳定层和浮动层两层，稳定层是导航、主内容容器这种骨架，浮动层是随模式切换的工具栏、提示条和上下文面板。稳定层在模式切换时不参与更新，只有浮动层发生变化，输入框只要属于稳定层，就不会被重建。这套拆法能让大部分输入丢失问题直接消失。

4.3 调试：把上下文状态可视化

context-mode 逻辑越复杂，越需要一个能“看见状态”的调试工具。我早期靠 console.log 打印对象，但随着栈和模式逐步复杂，日志很快就淹没在大量无关输出里了。后来我做了一个小工具：在开发模式下，往页面右下角叠加一个半透明面板，实时列出当前 context 栈、栈顶 meta、当前模式和最近三次切换记录，每次压栈弹栈都会高亮一次。这样在操作界面时，我能同时看到内部状态的变化，定位问题快了很多。

这个可视化面板还可以配合录制回放功能。我会固定一组操作步骤，比如“点开草稿箱 -> 打开邮件 -> 选中附件 -> 按 Esc”，然后把每一步之前和之后的上下文栈拍成快照。发生异常时，把快照对比一下，就能发现到底哪一步没有如预期压栈，哪一步多弹了一层。

最后是一个很实用的技巧：把 context 栈变化写入本地存储或远程日志，用户报告问题后，直接回放他的栈变化过程，比反复让用户复现操作要高效得多。尤其是在一些难以稳定复现的“偶发闪烁”问题上，这个手段几乎是唯一能抓到现场的方式。

4.4 性能优化：避免整棵树重建

context-mode 的常规实现容易造成一个性能隐患：每次模式切换都触发一个较高级别组件的状态更新，导致没办法精准控制影响边界。打个比方，一只蚂蚁踩了一下拉环，结果整栋楼的消防喷淋全开了，界面大范围重建，卡顿自然就来了。

优化思路是从“响应式更新”换成“命令式更新”。模式切换的本质，往往是往一个容器里塞入一组新的操作按钮，或者把一个面板的出现状态改一下。这些都不需要让前端框架重新 diff 整个页面。我实现 contextManager 的时候，模式回调里尽量避免用全局状态，而是直接拿到目标 DOM 容器，使用命令式的方式插入或清空节点。这样做有两个好处：一是性能不受页面规模影响，二是避免了 React 这类自动 diff 机制带来的额外开销。不过如果团队已经深度使用响应式框架，那么至少也要做到把模式状态限定在几个专用的“模式组件”里，其他组件不要订阅它。

为了保证动画流畅，我还会把 DOM 更新步骤合并进 requestAnimationFrame 中。也就是说，同一帧内哪怕发生了三次模式重算，也只执行一次真实渲染。这个节流操作能明显减少闪烁，尤其当模式切换触发点比较密集时，收益很可观。具体实现很简单，把要执行渲染的动作放到一个队列里，在 requestAnimationFrame 回调里统一处理，时间戳记录当前帧的最后一次状态即可。

5. 后续还可以这样扩展：给 context-mode 装上“记忆”

如果你把基础版 context-mode 跑通之后，还想继续提升体验，我建议在“记忆”上做文章。基础版是根据当下的操作来识别上下文，但用户其实是连续行为组成的任务流。比如用户每次处理某类工单时，都会先打开详情，再点备注，再关闭。如果系统记住了这个序列，在下一次用户打开详情后，就能直接预测下一步是打开备注栏，并把备注入口提前展示出来。这是一种从“响应式 context-mode”走向“预测式 context-mode”的升级，也是我认为这个方向最有想象力的延伸。

实现记忆机制并不一定要引入多复杂的模型。我试过的方案是：把每次从压栈到弹栈的完整轨迹，记录成一个由上下文 ID 组成的序列，然后统计相同序列出现的频次。一旦某个序列出现次数超过设定阈值，就把它视为一个“习惯模式”，在运行时从当前轨迹匹配最接近的历史序列，匹配成功则提前切换到一个预判模式。这个方案的成本很低，但对重复性任务的提效非常明显。

需要提醒的是，记忆机制一定要给用户“反悔”的出口。预判出来的模式如果不合适，必须能一键回到默认模式，并取消这次预判学习。否则用户会觉得自己被系统牵着走，反而丢了掌控感。

说回个人体会，我做了好几个版本之后，最深的感受是：模式是状态的影子。不要试图用几百个 if/else 去管理界面，先把用户所处的上下文结构想清楚，把状态栈建好，context-mode 自然就变成一个“状态到界面的投影”而已。另外，一定要给上下文栈做可视化，这个习惯帮我省下的排查时间，比我预想的多了一个数量级。