如果你在编辑器里选中一段文字后旁边会自动浮出“加粗、引用、复制”这一组操作而在聊天窗口里长按一条消息弹出来的却是“复制、转发、撤回”另一个菜单——你正在体验的就是 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] };用表格总结一下参数选择建议参数建议取值过小的影响过大的影响行为阈值3 次左右容易误触发模式响应迟钝用户觉得不跟手超时时间2000ms 左右模式上下文过早过期过期上下文长时间干扰界面优先级顺序临时行为优先模式互相覆盖短期操作无法抢占界面4. 常见问题与排查技巧实录4.1 上下文抖动与切换死循环我在实际调试中遇到最多的问题就是“抖动”现象。外在表现是模式刚切过来马上又切回去或者两个模式不断交替出现界面像霓虹灯一样闪。原因通常有两个一是 resolver 里对上下文的判断不完整同一个事件同时满足两个模式的进入条件导致 recompute 反复横跳二是上下文栈压入和弹出的时机撞在了一起压栈操作触发了一次 recompute紧接着弹栈又触发了一次。解决办法也很直接。首先在 recompute 里对比 mode 是否变化这能挡掉一部分无意义的重入。其次引入一个“模式稳定窗口”每次切换完成后在 200ms 内忽略新的切换请求。这个窗口不是硬编码在条件里的而是用一个时间戳记录上次切换时间如果当前时间距上次切换小于窗口值就只更新 mode 标记不执行渲染。最后给 resolver 设置一个明确的优先级表让“多个上下文同时满足”变成一个可预测的输出。排查抖动时我会用日志把每次 recompute 的触发原因记录下来输出当前栈、输入上下文、输出模式和触发事件源。日志格式类似这样[recompute] stackpageeditorselection, inputselection, outputtext-actions, reasonselectionchange然后我回放整个操作序列观察到底是哪一步让两个模式互相抢占。绝大多数情况下日志会比人眼盯着界面更早发现问题。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 自然就变成一个“状态到界面的投影”而已。另外一定要给上下文栈做可视化这个习惯帮我省下的排查时间比我预想的多了一个数量级。 
长河君 · 2026/10/20 3:56:59 · 阅读 1.2k Context-Mode实战：用上下文栈驱动界面状态与交互切换
如果你在编辑器里选中一段文字后旁边会自动浮出“加粗、引用、复制”这一组操作而在聊天窗口里长按一条消息弹出来的却是“复制、转发、撤回”另一个菜单——你正在体验的就是 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] };用表格总结一下参数选择建议参数建议取值过小的影响过大的影响行为阈值3 次左右容易误触发模式响应迟钝用户觉得不跟手超时时间2000ms 左右模式上下文过早过期过期上下文长时间干扰界面优先级顺序临时行为优先模式互相覆盖短期操作无法抢占界面4. 常见问题与排查技巧实录4.1 上下文抖动与切换死循环我在实际调试中遇到最多的问题就是“抖动”现象。外在表现是模式刚切过来马上又切回去或者两个模式不断交替出现界面像霓虹灯一样闪。原因通常有两个一是 resolver 里对上下文的判断不完整同一个事件同时满足两个模式的进入条件导致 recompute 反复横跳二是上下文栈压入和弹出的时机撞在了一起压栈操作触发了一次 recompute紧接着弹栈又触发了一次。解决办法也很直接。首先在 recompute 里对比 mode 是否变化这能挡掉一部分无意义的重入。其次引入一个“模式稳定窗口”每次切换完成后在 200ms 内忽略新的切换请求。这个窗口不是硬编码在条件里的而是用一个时间戳记录上次切换时间如果当前时间距上次切换小于窗口值就只更新 mode 标记不执行渲染。最后给 resolver 设置一个明确的优先级表让“多个上下文同时满足”变成一个可预测的输出。排查抖动时我会用日志把每次 recompute 的触发原因记录下来输出当前栈、输入上下文、输出模式和触发事件源。日志格式类似这样[recompute] stackpageeditorselection, inputselection, outputtext-actions, reasonselectionchange然后我回放整个操作序列观察到底是哪一步让两个模式互相抢占。绝大多数情况下日志会比人眼盯着界面更早发现问题。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 自然就变成一个“状态到界面的投影”而已。另外一定要给上下文栈做可视化这个习惯帮我省下的排查时间比我预想的多了一个数量级。