context-mode 上下文模式：从条件判断到状态机与上下文栈的工程实践

1. 从"上下文模式"这个命名说起：它到底在解决什么问题

第一次看到"context-mode"这个词，很多人会下意识觉得它是个抽象概念，甚至怀疑它是不是又一个被过度包装的技术名词。但如果你真正在工程一线待过，尤其是在做对话系统、状态机、或者任何需要"记住当前处境"的模块时，你会发现这个词背后藏着一个非常具体、非常要命的工程问题：同一个功能，在不同上下文里应该表现出不同的行为，而代码却往往把它们写死成了一套逻辑。

举个最直白的例子。一个文本处理工具，在"编辑模式"下用户敲键盘应该直接修改内容；在"预览模式"下敲键盘应该触发翻页或缩放；在"命令模式"下敲键盘应该被解析成指令。这三种行为如果全部塞进一个函数里，用一堆 if-else 判断当前状态，代码会迅速膨胀成一团乱麻。而 context-mode 要做的，就是把这套"当前处于什么处境、该走哪条逻辑分支"的决策，从散落各处的条件判断里抽出来，变成一个可配置、可切换、可扩展的独立层。

我之所以对这个标题有感觉，是因为过去几年里我至少在三类项目里反复遇到过同一个坑：状态和行为的耦合。早期写一个简单的画板工具，画笔、橡皮、取色器三个工具，每个工具对鼠标事件的处理都不一样。最开始我的写法是每个事件回调里判断currentTool === 'brush'还是'eraser'，代码写了两百行就开始失控——加一个新工具要改五六个地方，改一处忘一处就出 bug。后来我把每个工具封装成一个独立的 mode 对象，每个 mode 自己实现onMouseDown、onMouseMove、onMouseUp，主循环只负责把事件转发给当前 mode。代码量没减少多少，但可维护性完全是两个量级。

这就是 context-mode 的核心价值：它不是一个具体的库或框架，而是一种组织代码的思维方式——把"当前上下文"作为一等公民，让行为随上下文自然切换，而不是靠散落的条件判断去模拟。

这篇文章我会从几个层面把这件事讲透。先讲清楚 context-mode 的本质和它要解决的工程痛点，然后给出几种不同场景下的落地实现方案，接着重点讲我在实际项目里踩过的坑——尤其是状态切换时的边界问题，这部分是文档里绝对不会写的。最后会聊一聊怎么把这套思路扩展到更复杂的场景，比如嵌套上下文、上下文栈、以及和异步流程的配合。无论你是做前端交互、后端状态机、还是游戏逻辑，这套思路都能直接拿去用。

2. 拆解 context-mode 的本质：上下文、模式、以及两者的关系

2.1 上下文不是"状态"，虽然它们经常被混为一谈

很多人一上来就把 context 等同于 state，这是第一个容易踩的认知坑。状态（state）描述的是"系统当前是什么样"，比如"当前选中了红色画笔""当前文档有 3 个图层"。而上下文（context）描述的是"系统当前处于什么处境、接下来该按哪套规则行事"，它更像是一个行为的分发依据。

打个比方。你走进一家餐厅，你的"状态"可能是"饿了""带了 200 块钱"；而你的"上下文"是"我现在是在点餐阶段、用餐阶段还是结账阶段"。不同阶段下，你和服务员的交互规则完全不同——点餐时你翻菜单，用餐时你动筷子，结账时你掏钱包。状态可以贯穿所有阶段不变，但上下文决定了你此刻该做什么。

在代码里，这个区别体现得非常明显。状态通常是数据，存在一个对象里；而上下文往往还绑定了行为集合——也就是这个上下文下，各类事件应该怎么响应。context-mode 里的 "mode" 这个词，强调的正是这层行为绑定。

2.2 mode 的本质：一组行为的封装单元

一个 mode 应该包含什么？我的经验是至少三样东西：进入时的初始化逻辑、退出时的清理逻辑、以及在该模式下对各类输入/事件的响应逻辑。

const brushMode = { name: 'brush', onEnter(ctx) { ctx.cursor = 'crosshair'; ctx.activeLayer.beginStroke(); }, onExit(ctx) { ctx.activeLayer.endStroke(); ctx.cursor = 'default'; }, onPointerDown(ctx, e) { ctx.activeLayer.startPoint(e.x, e.y); }, onPointerMove(ctx, e) { if (ctx.isDrawing) ctx.activeLayer.addPoint(e.x, e.y); }, onPointerUp(ctx) { ctx.isDrawing = false; } };

这段代码看起来平平无奇，但它解决了一个关键问题：所有和"画笔模式"相关的逻辑都聚在一起了。你要改画笔的行为，只看这一个对象就够了；你要加一个新模式，复制这个结构改一改就行，完全不用碰主循环。这就是封装带来的隔离性。

2.3 为什么"模式切换"比"条件判断"更抗腐化

我做过一个粗略的统计。在一个中等复杂度的交互项目里，如果用 if-else 判断当前模式，平均每增加一个新模式，需要修改的代码点大约是 4 到 7 处。而用 mode 对象的方式，新增模式只需要新增一个对象，再在注册表里加一行，修改点稳定在 1 到 2 处。

这个差距在项目初期不明显，但到了后期是致命的。因为每多一个修改点，就多一个"改漏了"的风险。我见过最夸张的一个案例，一个编辑器项目里判断模式的 if-else 散落在十几个文件里，结果新增一个"只读模式"时，漏改了一个复制粘贴的处理逻辑，导致只读模式下居然还能粘贴内容，上线后才发现。

提示：判断一个项目该不该引入 context-mode 架构，有个简单的信号——如果你发现自己在多个地方重复写"根据当前状态决定行为"的判断，那就是时候重构了。

3. 三种落地形态：从轻量对象到完整状态机

context-mode 不是一个必须依赖某个库才能实现的东西。根据项目复杂度，我把它分成三种落地形态，你可以按需选择。

3.1 轻量形态：一个注册表加一组对象

这是最简单也最常用的形态，适合模式数量在 10 个以内、模式之间切换逻辑不复杂的场景。核心就是一个注册表（通常是个 Map 或普通对象）加上当前模式的引用。

class ModeManager { constructor() { this.modes = new Map(); this.current = null; } register(mode) { this.modes.set(mode.name, mode); } switchTo(name, ctx) { if (this.current === this.modes.get(name)) return; if (this.current && this.current.onExit) { this.current.onExit(ctx); } this.current = this.modes.get(name); if (this.current && this.current.onEnter) { this.current.onEnter(ctx); } } dispatch(eventName, ctx, ...args) { if (this.current && typeof this.current[eventName] === 'function') { return this.current[eventName](ctx, ...args); } } }

用起来也很直接：

const manager = new ModeManager(); manager.register(brushMode); manager.register(eraserMode); manager.register(selectMode); manager.switchTo('brush', ctx); canvas.addEventListener('pointerdown', (e) => manager.dispatch('onPointerDown', ctx, e));

这个形态的好处是零依赖、易理解、调试方便。缺点是它不处理模式之间的转换规则——比如"画笔模式下按 Esc 应该切到选择模式"这种逻辑，你得自己写在某个地方。

3.2 中等形态：带转换规则的状态机

当模式之间的切换开始有明确规则时，就该引入转换表了。这时候 context-mode 就演变成了一个有限状态机（FSM）。

const transitions = { brush: { ESC: 'select', KEY_B: 'brush' }, eraser: { ESC: 'select', KEY_E: 'eraser' }, select: { KEY_B: 'brush', KEY_E: 'eraser', ENTER: 'edit' }, edit: { ESC: 'select' } }; function handleKey(key, currentMode) { const rule = transitions[currentMode]; if (rule && rule[key]) { return rule[key]; } return currentMode; }

转换表的好处是把"什么情况下切到哪个模式"这件事集中管理了。你一眼就能看出整个系统的模式流转关系，不用去翻每个 mode 的实现。这在做复杂交互时特别有用，因为模式之间的转换规则往往比模式本身更容易出错。

3.3 完整形态：带上下文栈的嵌套模式

真正复杂的场景里，模式是可以嵌套的。比如一个编辑器，整体处于"编辑模式"，但编辑模式下可能临时弹出一个"查找替换"面板，这个面板自己又有一套输入规则。这时候你需要的是一个上下文栈，而不是单个当前模式。

class ContextStack { constructor() { this.stack = []; } push(mode, ctx) { if (this.top() && this.top().onPause) this.top().onPause(ctx); this.stack.push(mode); if (mode.onEnter) mode.onEnter(ctx); } pop(ctx) { const mode = this.stack.pop(); if (mode && mode.onExit) mode.onExit(ctx); if (this.top() && this.top().onResume) this.top().onResume(ctx); } top() { return this.stack[this.stack.length - 1]; } dispatch(eventName, ctx, ...args) { const mode = this.top(); if (mode && typeof mode[eventName] === 'function') { return mode[eventName](ctx, ...args); } } }

注意这里多了onPause和onResume两个钩子。这是嵌套模式的关键——当上层模式被下层覆盖时，它需要"暂停"而不是"退出"，因为它的状态要保留，等下层弹出后还要恢复。这个细节我在第一次实现嵌套模式时完全没考虑到，结果弹出查找面板再关闭后，原来的编辑状态全丢了，用户得重新选一遍。后来加上 pause/resume 才解决。

4. 状态切换时的边界问题：我踩过的四个坑

这部分是全文最值钱的地方。context-mode 的架构本身不难，难的是切换瞬间的边界处理。下面四个坑，每一个我都真实踩过，而且每一个在文档里都找不到。

4.1 坑一：切换时旧模式的清理逻辑没跑完就进了新模式

最典型的表现是资源泄漏。比如画笔模式在onEnter时开启了一个动画帧循环，切走时onExit应该取消它。但如果切换逻辑写成了"先设置新模式，再调用旧模式的 onExit"，就会出现旧模式的清理逻辑读到的是新模式的数据，导致清理失败。

正确的顺序永远是：先完整退出旧模式，再进入新模式。中间不要插入任何其他操作。

switchTo(name, ctx) { if (this.current) { this.current.onExit(ctx); // 先彻底退出 } this.current = this.modes.get(name); if (this.current) { this.current.onEnter(ctx); // 再进入 } }

4.2 坑二：切换过程中触发了新的事件，导致重入

这个坑更隐蔽。假设你在onExit里做了一些清理，清理过程中可能触发某个事件（比如取消动画时触发了animationend），而这个事件又被分发给了"当前模式"。如果此时this.current已经被改成了新模式，那这个本该属于旧模式的事件就跑到了新模式里，轻则逻辑错乱，重则死循环。

我的解法是加一个isSwitching标志位，切换期间直接丢弃所有分发的事件：

switchTo(name, ctx) { this.isSwitching = true; try { if (this.current) this.current.onExit(ctx); this.current = this.modes.get(name); if (this.current) this.current.onEnter(ctx); } finally { this.isSwitching = false; } } dispatch(eventName, ctx, ...args) { if (this.isSwitching) return; // ... }

4.3 坑三：异步操作在切换后回调，操作了错误的上下文

这是异步场景下的经典问题。比如在画笔模式下发起了一个异步的保存操作，保存完成后回调里想更新画笔状态。但用户可能在保存期间切到了橡皮模式，回调执行时上下文已经变了。

解法有两种。一种是在回调里检查当前模式是否还是发起时的模式：

const modeAtStart = this.current; doAsyncSave().then(() => { if (this.current !== modeAtStart) return; // 上下文已变，放弃 // 更新画笔状态 });

另一种是给每次切换打一个版本号，回调里比对版本号。我一般用第一种，简单直接。

4.4 坑四：模式切换的幂等性被破坏

有时候同一个切换请求会被触发多次，比如用户快速连按两次快捷键。如果切换逻辑不幂等，第二次切换可能会把刚进入的模式又退出一次，导致状态错乱。

switchTo(name, ctx) { if (this.current === this.modes.get(name)) return; // 幂等保护 // ... }

这一行if看起来不起眼，但能挡掉大量诡异 bug。我建议所有切换入口都加上这个判断。

注意：这四个坑的共同点是——它们都发生在"切换的瞬间"，而不是"某个模式内部"。这也是为什么 context-mode 的难点不在模式本身，而在模式之间的衔接。

5. 把 context-mode 用到实际项目里：一个完整的交互案例

光讲原理容易空。我用一个完整的例子把前面所有东西串起来——一个支持多模式的图形编辑器核心。

5.1 定义上下文对象

上下文对象是所有模式共享的数据载体，它应该只放数据，不放行为。

const ctx = { canvas: document.getElementById('canvas'), activeLayer: null, selectedShape: null, isDrawing: false, cursor: 'default', history: [] };

5.2 实现三个核心模式

const selectMode = { name: 'select', onEnter(ctx) { ctx.cursor = 'default'; }, onPointerDown(ctx, e) { ctx.selectedShape = hitTest(ctx, e.x, e.y); }, onKeyDown(ctx, e) { if (e.key === 'Delete' && ctx.selectedShape) { removeShape(ctx, ctx.selectedShape); ctx.selectedShape = null; } } }; const brushMode = { name: 'brush', onEnter(ctx) { ctx.cursor = 'crosshair'; }, onPointerDown(ctx, e) { ctx.isDrawing = true; ctx.activeLayer = createStroke(ctx, e.x, e.y); }, onPointerMove(ctx, e) { if (ctx.isDrawing) appendPoint(ctx.activeLayer, e.x, e.y); }, onPointerUp(ctx) { ctx.isDrawing = false; pushHistory(ctx, ctx.activeLayer); } }; const eraserMode = { name: 'eraser', onEnter(ctx) { ctx.cursor = 'cell'; }, onPointerDown(ctx, e) { ctx.isErasing = true; eraseAt(ctx, e.x, e.y); }, onPointerMove(ctx, e) { if (ctx.isErasing) eraseAt(ctx, e.x, e.y); }, onPointerUp(ctx) { ctx.isErasing = false; } };

5.3 组装管理器并绑定事件

const manager = new ModeManager(); manager.register(selectMode); manager.register(brushMode); manager.register(eraserMode); manager.switchTo('select', ctx); ctx.canvas.addEventListener('pointerdown', (e) => manager.dispatch('onPointerDown', ctx, e)); ctx.canvas.addEventListener('pointermove', (e) => manager.dispatch('onPointerMove', ctx, e)); ctx.canvas.addEventListener('pointerup', (e) => manager.dispatch('onPointerUp', ctx, e)); window.addEventListener('keydown', (e) => { if (e.key === 'b') manager.switchTo('brush', ctx); else if (e.key === 'e') manager.switchTo('eraser', ctx); else if (e.key === 'Escape') manager.switchTo('select', ctx); else manager.dispatch('onKeyDown', ctx, e); });

这套代码跑起来之后，你会发现一个很舒服的特性：加新功能几乎不用改老代码。想加一个"矩形工具"，只需要写一个 rectMode 对象，注册进去，在快捷键里加一行。老模式一行都不用动。这就是 context-mode 架构的复利。

5.4 实测中的性能考量

有人可能会担心：每次事件都经过一层 dispatch，会不会有性能损耗？我实测下来，在每秒几百次 pointermove 的场景下，这层间接调用的开销完全可以忽略——现代 JS 引擎对属性查找和函数调用的优化非常好。真正影响性能的是模式内部的处理逻辑，而不是这层分发。

不过有一个细节值得注意：dispatch 里不要做任何重活。我见过有人在 dispatch 里做事件过滤、坐标转换、甚至权限检查，结果这层变成了瓶颈。正确的做法是 dispatch 只负责转发，重活放在模式内部或者事件进入 dispatch 之前。

6. 扩展思路：当 context-mode 遇上更复杂的场景

6.1 和异步流程的配合

现代应用里，很多操作是异步的。context-mode 和异步配合时，核心原则是：上下文切换是同步的，异步操作要显式绑定它所属的上下文。我通常会在异步操作发起时记录当前模式，回调时校验。

6.2 上下文的持久化与恢复

有些场景需要把当前上下文存下来，下次打开时恢复。这时候要注意：只持久化数据，不持久化行为。模式对象是代码，不该被序列化；需要存的是"当前处于哪个模式"以及上下文数据。恢复时先重建模式注册表，再根据存下来的模式名切换过去。

6.3 多实例隔离

如果一个页面里有多个独立的编辑器实例，每个实例应该有自己独立的 ModeManager 和 ctx，不要共用。共用会导致一个实例的模式切换影响另一个实例。这个坑我在做多标签编辑器时踩过，两个标签页的模式互相干扰，排查了半天才发现是管理器被写成了单例。

6.4 调试技巧：给模式切换加日志

context-mode 架构的一个副作用是，出问题时你不太容易一眼看出"当前到底在哪个模式"。我的习惯是在 switchTo 里加一行日志，记录切换前后的模式名和时间戳。上线前可以关掉，但开发期这行日志能省下大量排查时间。

switchTo(name, ctx) { if (this.current === this.modes.get(name)) return; console.log(`[mode] ${this.current?.name ?? 'none'} -> ${name}`); // ... }

7. 关于 context-mode 的一些个人体会

这套东西我用了好几年，最大的感受是：它的价值不在于代码写得多漂亮，而在于它把"变化"关进了一个可控的盒子里。需求变化是必然的，新模式、新模式之间的转换规则会不断冒出来。如果这些变化散落在代码各处，每次改动都是一次冒险；如果它们被收敛到模式对象和转换表里，改动就变成了可预测的、局部的操作。

另一个体会是，不要过度设计。我见过有人一上来就搞上下文栈、搞转换表、搞插件系统，结果项目里其实只有两个模式，切换逻辑简单得不能再简单。这种时候，一个 Map 加一个 current 变量就够了。架构要跟着复杂度走，而不是反过来。

最后一个实用建议：先把模式边界画清楚，再写代码。我现在的习惯是，动手前先在纸上列出所有模式，以及每个模式下"哪些事件有特殊处理、哪些事件忽略"。这张表画清楚了，代码基本就是照着抄。画不清楚，写出来的代码大概率要返工。这个习惯帮我省下的时间，比任何编码技巧都多。