最早让我决定做一个 context-mode 项目，是因为一个特别具体的痛点：同一套应用，放在办公室、通勤路上、家里、深夜加班这些不同场景里，使用者的操作习惯和真实需求完全不一样。白天在公司网络下打开后台，你可能希望默认加载完整数据表格；到了晚上用手机流量访问，你可能只想快速看一个核心指标；开会时屏幕被投出来，你反而希望隐藏所有敏感字段。过去这些都得靠用户手动切主题、切视图、切功能开关，做多了用户烦，也根本记不住。我当时就在想，能不能让应用自己感知出“现在处于什么上下文”，然后主动切换到对应的模式。这就是 context-mode 的由来。这个项目本质上是一个“上下文感知的模式切换引擎”。它做的事情很简单：把环境信息、设备信息、时间信息、网络信息等采集起来，通过一组可配置的规则实时判断当前应该处于哪种模式，然后自动完成界面、行为、权限策略的切换。它适合的范围很广：前端页面、客户端工具、内部管理系统、甚至物联网边缘设备上都用得到。对于写过一段时间业务系统、开始被各种“环境适配”问题折磨的开发者来说，这是一个可以直接参考的方案。1. 项目背景与核心价值拆解1.1 为什么常规的“用户设置”模式不够用大多数应用目前的模式切换都靠用户主动操作，比如手动切换夜间模式、手动切换“简洁视图”。这套做法在小功能上没问题，但一旦模式的数量变多，问题就来了。第一个问题是记忆负担，用户根本不知道这个系统支持多少种模式，更不知道当前状态下用哪个模式最合适。第二个问题是切换成本，移动端随手切一下还好，后台系统里找设置项可能要点三四层菜单。第三个问题是错失时机，午夜还在写报告的用户不会想起来去开夜间模式，地铁上刚打开弱网环境的用户不会主动去关高清图片加载。这三个问题的根源是一致的：用户当前的上下文已经包含足够多的判断信息，但应用没有读取它们。时间、地理位置、网络类型、设备电量、屏幕亮度、当前日历事件，这些都是现成的上下文数据，完全可以组合起来推断出用户意图。context-mode 的出发点就是把这部分信号利用起来，让系统主动服务，而不是等待用户发号施令。1.2 核心解决的问题与基本盘这个项目解决的核心问题可以拆成四个层次。最底层是上下文采集，把分散在浏览器、客户端、传感器中的零散数据统一成结构化快照。往上一层是规则匹配，把业务人员能理解的各种判断条件翻译成可执行的匹配逻辑。再往上是模式切换，保证模式变化是平滑的、可回退的、不会来回抖动。最上层是运营能力，要让非开发人员也能通过配置中心调整规则，而不是每次改规则都发一次版本。这四个层次里，前两个是技术核心，后两个是工程落地关键。很多类似方案在 demo 阶段跑得很顺，一上生产就出问题，基本都是栽在后两层：模式切换乱跳、规则配置不灵活、出了问题不知道如何排查。所以 context-mode 在设计时就把“可观测性”和“防抖机制”当作一等公民，而不是后期补丁。1.3 适用场景与目标使用者画像如果你是做前端应用的，它可以让同一套页面在不同环境下自动调整布局、主题、数据加载策略。如果你在做客户端工具，它可以根据用户是在开会、在演示、还是在远程调试，自动切换功能可见性和通知策略。如果你在维护内部管理系统，它能帮你在投屏场景下自动隐藏敏感栏位，在公司网络环境下自动开启大文件缓存。具体来说，适合读这篇文章的人包括这么几类：被“不同环境不同行为”折磨的业务前端开发者；正在设计规则引擎、又不想从零写一套的架构师；以及那些做 IoT 网关、需要根据时段和网络状态调整上报策略的嵌入式开发朋友。后面我讲的实现思路不绑定具体框架，核心逻辑都是通用的。2. 整体架构设计：从上下文采集到模式切换2.1 设计目标与核心取舍我在动手之前定了四个设计目标，这四点影响了后续所有决策。第一是采集层必须可插拔，不能让业务代码与具体 API 强耦合，比如今天用浏览器的 Network Information API，明天换客户端的原生上报，采集器应该只是实现同一个接口的不同插件。第二是匹配规则必须数据驱动，规则的增删改不能靠改代码完成，要能序列化成 JSON、能中心化下发。第三是模式切换必须可控，绝不能出现“1 秒内切换 20 次”的抖动情况，必须有防抖、有最小间隔、有回退策略。第四点很多人会忽略，就是匹配过程必须无副作用。匹配引擎只负责算出一个“建议模式”，真正执行切换的是分发器。把这两个阶段分开之后，测试变得非常简单：你可以不看界面，直接构造上下文快照喂给匹配器，断言它输出的是哪个模式。我实际开发中体会很深，一旦匹配和执行耦合在一起，每次调试都要刷新页面、点击操作、观察变化，效率非常低。2.2 上下文快照的数据结构所有采集器最终都把数据汇总成一个上下文快照，这是一个纯普通对象，不包含任何方法，方便序列化和比较。我定义的数据结构大致是这样：interface ContextSnapshot { timestamp: number; time: { hour: number; // 0-23 weekday: number; // 0-6，0 表示周日 isWorkday: boolean; }; network: { kind: 'wifi' | 'cellular' | 'ethernet' | 'none' | 'unknown'; downlinkMbps?: number; // 实测下行速度，可缺省 isSlow: boolean; // 是否低于定义的低速阈值 }; location: { kind: 'office' | 'home' | 'transit' | 'unrecognized'; distanceToOffice?: number; // 米，可缺省 }; device: { batteryPercent: number; // 0-100，-1 表示未知 screenBrightness: number; // 0-1 isPresenting: boolean; // 是否检测到投屏/外接显示 pointerType: 'fine' | 'coarse'; // 鼠标还是触屏 }; app: { foreground: boolean; lastActiveAt: number; }; }为什么用扁平结构而不是嵌套分类？因为规则匹配的时候经常要做跨维度判断，比如“晚上九点且电量低于 20%”，扁平结构在规则函数里写起来最顺手。这个结构不是一次定死的，随着业务增加字段就好，但要注意兼容性：新增字段不能破坏旧规则，所以规则引擎里对字段访问必须做容错，默认给中性的值。2.3 模式规则模型与匹配优先级规则是 context-mode 里最核心的抽象。我设计成每条规则都不直接写死“等于某个模式”，而是包含条件、模式、优先级、权重、有效期这些字段：interface ModeRule { id: string; mode: string; // 命中的模式名称 priority: number; // 模式级优先级，数字越大越优先 condition: (ctx: ContextSnapshot) => boolean; weight: Record<string, number>; // 可选的打分项 expiresAt?: number; // 过期时间戳，默认 0 表示长期有效 }条件函数返回布尔值，是最简单直白的判断。打分机制是为了处理那些“多个条件都没完全命中，但部分信号很强”的场景。比如“深夜”和“低电量”两个条件，任何一个单独出现都不足以断定用户需要省电模式，但两个同时出现时，系统可以通过加权得分超过阈值，切到省电模式。模式之间的冲突处理我用两级策略。第一级用 priority，只保留命中规则里优先级最高的。第二级是对相同优先级的规则做加权求和，谁的得分高谁生效。如果所有规则都没命中，就返回默认模式。这套规则在设计时就要想清楚，不然线上会出现不可预测的“随机模式”。2.4 架构分层与模块边界整个项目我分成四个模块，模块之间依赖方向是单向的，不允许反向调用。采集端（source）：负责从不同数据源拿原始数据，转换成上下文快照的局部字段。引擎端（engine）：接收完整快照，执行规则匹配，产出建议模式。分发端（dispatcher）：监听引擎输出，处理防抖、持久化、用户覆盖，然后回调业务层。配置端（config）：维护规则列表、默认模式、阈值参数，支持本地或远端下发。依赖单向的好处有两个。一个是调试时随时可以用一个假快照替换真实采集端，完全不影响引擎和分发器。另一个是多个业务模块可以共用同一个引擎实例，保证规则的一致性。我试过在某个模拟项目里同时让页面主题、通知策略、数据预取开关三处消费同一个模式，正是因为共用一个引擎，才没有出现各切各的错乱情况。3. 核心实现细节：匹配引擎与切换机制3.1 采集器：如何做可插拔的设计每个采集器最简单粗暴的实现就是一个函数：负责把系统环境的信息读取出来，做归一化，写回快照对应的字段。我在项目里写了一个 Source 接口：interface ContextSource { key: string; // 例如 'time', 'network', 'location' collect(): Partial<ContextSnapshot>; destroy?(): void; // 需要清理监听器时使用 }在实现网络状态采集器时，浏览器里最直接的是 Network Information API，可以拿到 downlink 和 effectiveType。但这个 API 的语义在不同内核里并不完全一致，有的浏览器 downlink 返回的是理论值，有的返回的是估算值。所以我并不直接拿它当“低速”判断依据，而是结合一个简单的测速样本：拉取一个小的静态资源，记录耗时时长，再把两个信号融合。实测下来，用“理论值 + 实测样本”双信号判断低速，比单用任何一个都稳。采集器的注册使用简单工厂模式。引擎启动时调用 registerSource() 把各个采集器挂上去，引擎会按注册顺序依次执行，最后合成一份完整快照。销毁时会有清理逻辑，防止在 React StrictMode 或客户端热更新场景下重复注册导致监听器泄漏。3.2 规则匹配算法：条件过滤、加权评分、优先级仲裁匹配过程的代码风格偏函数式，核心思路是三步走：function matchMode(ctx: ContextSnapshot, rules: ModeRule[]): MatchResult { const activeRules = rules .filter(rule => rule.expiresAt && rule.expiresAt > Date.now() ? false : true) .map(rule => ({ rule, pass: rule.condition(ctx) })); const matched = activeRules.filter(item => item.pass); if (matched.length === 0) { return { mode: config.defaultMode, reasons: [], confidence: 0 }; } // 同一模式内算加权总分 const scored = matched.reduce((acc, item) => { const mode = item.rule.mode; const score = Object.entries(item.rule.weight || {}) .reduce((sum, [key, w]) => sum + (ctx[key] ? w : 0), 0); if (!acc.has(mode) || score > acc.get(mode).score) { acc.set(mode, { score, priority: item.rule.priority }); } return acc; }, new Map()); // 模式间按优先级仲裁 let bestMode = config.defaultMode; let bestPriority = -Infinity; for (const [mode, info] of scored) { if (info.priority > bestPriority) { bestMode = mode; bestPriority = info.priority; } } return { mode: bestMode, reasons: matched.map(item => item.rule.id), confidence: bestPriority }; }条件规则我建议写成“单独的小布尔函数”而不是一大段表达式。比如 isNightAtHome(ctx)、isWeakNetwork(ctx)、isWorkMeeting(ctx)，每个函数只判断一件事。这样规则配置可视化时，可以直接用“且 / 或 / 非”组装，也便于测试覆盖率统计。真要把复杂业务规则堆进一个函数里，后期新同学接手会非常想骂人。3.3 分发器：防抖、最小间隔和回退策略刚开始做 context-mode 时，最不满意的地方就是模式抖动。地理位置在办公室边界附近时，location 采集器一会返回 office、一会返回 unrecognized，结果模式在“工作模式”和“标准模式”之间疯狂切换。不加控制的话，界面主题就会不停跳动，用户观感极差。后来我加了三个机制。第一个是去抖等待，引擎算出一个新建议模式后，不立刻执行，而是先放进一个 pending 状态，等待 800ms 内不再出现新建议才提交。第二个是最小切换间隔，即使连续两个建议模式不同，也必须距离上一次切换超过 1.2 秒才允许再次切换。第三个是粘性偏好，如果新建议模式的置信度不比当前模式高出一个阈值，继续保持当前模式。这三个机制组合在一起，效果很明显。我在模拟项目里反复横跳地切换网络状态，最终日志显示面积最小的切换间隔也有 1.4 秒，界面完全不会出现闪烁感。需要注意的是，防抖不是越长越好，过长的去抖会让用户的真实操作被延迟响应，所以我建议把默认值控制在 800ms 到 1500ms 之间，并且支持按模式单独配置。3.4 用户覆盖与持久化策略自动模式再准，也要给用户一个“手动说了算”的出口。我在设计里专门加了一个手动覆盖层，用户一旦手动选择某个模式，系统就把它写入 localStorage（或者客户端的本地配置库），并且附带一个过期时间。过期之前的匹配流程会先检查覆盖层，有覆盖就用覆盖值，不再做自动判断。这个设计有几个细节值得分享。过期时间默认 4 小时，这样用户临时想在某个场合固定使用某个模式，不会一直固定到天荒地老；如果用户希望“本次启动内始终使用”，可以将过期时间设为 0，代表不自动过期。覆盖层必须与规则引擎隔离，不能把覆盖值混入上下文快照，否则会导致规则调试时数据源不干净。持久化数据的版本我也做了处理。规则配置会带一个 schemaVersion，本地缓存如果发现版本不匹配，会把过期的模式和规则一并丢弃，回退到默认配置。这个机制很关键，否则线上升级规则之后，老用户的本地还是会用旧逻辑跑很长时间。3.5 调试与可视化面板做规则引擎最容易遇到的问题就是“看不见”内部的决策过程。我特意在 context-mode 里内置了一个 debug 模式，它会开启一个事件总线，把每次匹配的完整链路发出去：原始快照有哪些字段、哪些规则被加载、哪些条件判定通过、最终模式从几个候选中胜出。在开发版里，我加了一个悬浮的小面板，展示当前快照、当前模式、匹配耗时、切换历史。真正上线之前直接打包关闭即可，不会留任何额外依赖。这个面板帮我在开发阶段省了大量时间，因为 UI 上的一个模式表现可能来自多层的规则组合，没有决策链路的话，排查效率极低。4. 实操环节：接入一个真实应用并跑通四种模式4.1 项目初始化与依赖选择接下来我用一个实际接入过程，演示从零开始跑通 context-mode。模拟的场景是一个企业内部的数据看板，我给它起名叫“模拟项目X”。这个看板需要支持四种模式：办公模式、通勤模式、夜间模式、演示模式。先初始化一个 Vite + React 的空项目，然后安装 context-mode 的核心包和 React 绑定包，整体依赖非常轻，核心包本身没有第三方运行时依赖。安装完成之后，在入口文件里初始化引擎、注册采集器、启动监听。import { createEngine } from 'context-mode'; import { timeSource } from 'context-mode/sources/time'; import { networkSource } from 'context-mode/sources/network'; import { geoSource } from 'context-mode/sources/geo'; import { presentationSource } from 'context-mode/sources/presentation'; const engine = createEngine({ defaultMode: 'standard', debounceMs: 800, minSwitchInterval: 1200, }); engine.registerSource(timeSource()); engine.registerSource(networkSource({ slowThresholdMbps: 1.2 })); engine.registerSource(geoSource({ officeRadiusMeters: 300 })); engine.registerSource(presentationSource()); engine.start();每个 source 的初始化函数我都配置了明确的参数。networkSource 的 slowThresholdMbps 设为 1.2，低于这个值就认为网络弱；geoSource 的 officeRadiusMeters 设为 300，距离办公室 300 米内才识别为办公地点。这些阈值不是拍脑袋定的，我是结合业务实际测量过的：公司周边三百米内信号稳定在 WiFi 覆盖区，超过这个范围就容易走蜂窝网络。4.2 定义四条模式规则规则在这个接入方案里写成一个单独的 rules.ts，方便后面接入配置中心时替换。const isOfficeTime = (ctx) => ctx.time.isWorkday && ctx.time.hour >= 9 && ctx.time.hour <= 18; const isLateNight = (ctx) => ctx.time.hour >= 22 || ctx.time.hour <= 5; const isInOffice = (ctx) => ctx.location.kind === 'office'; const isWeakNetwork = (ctx) => ctx.network.isSlow; const rules: ModeRule[] = [ { id: 'rule-office-time', mode: 'office', priority: 30, condition: (ctx) => isOfficeTime(ctx) && isInOffice(ctx), }, { id: 'rule-commute', mode: 'commute', priority: 25, condition: (ctx) => isWeakNetwork(ctx) && !isInOffice(ctx), weight: { 'ctx.network.isSlow': 10, 'ctx.time.isWorkday': 5 }, }, { id: 'rule-night', mode: 'night', priority: 35, condition: (ctx) => isLateNight(ctx), }, { id: 'rule-presentation', mode: 'presentation', priority: 40, condition: (ctx) => ctx.device.isPresenting, }, ];注意 rule-night 的优先级是 35，比 rule-office-time 高。这样即使深夜还在办公室加班，系统也会偏向夜间模式，优先照顾视觉舒适度；而演示模式的优先级最高，因为投屏场景是临时且强意图的，一旦检测到，其他所有模式都得让位。4.3 在 React 组件里消费模式变化React 侧我封装了一个 useMode() 钩子，内部订阅引擎的模式变化事件，并在卸载时取消订阅。function useMode(): string { const [mode, setMode] = useState(engine.getCurrentMode()); useEffect(() => { const unsubscribe = engine.subscribe((m) => setMode(m)); return unsubscribe; }, []); return mode; } function DashboardLayout() { const mode = useMode(); const themeClass = { office: 'theme-office', commute: 'theme-commute', night: 'theme-night', presentation: 'theme-presentation', standard: 'theme-standard', }[mode]; const showMetrics = mode !== 'presentation'; const heavyLoaded = mode === 'office'; return ( <div className={themeClass}> {showMetrics && <MetricsBoard />} {heavyLoaded && <DetailTable />} {mode === 'commute' && <CompactSummary />} {mode === 'night' && <NightOverlay />} </div> ); }这段代码里的关键点在于，模式变化时同一份数据可以驱动 UI 层和业务层同时变化。比如 showMetrics 控制敏感模块是否渲染，heavyLoaded 控制是否发起重数据请求，themeClass 控制视觉风格。整个接入过程中，我没有在业务组件里写过任何 if (new Date().getHours() > 22) 这类判断，全部收敛到模式层。4.4 实测结果与性能开销把这个接入方案跑起来之后，我观察了一组真实行为：白天在办公室打开看板，自动切到办公模式，完整表格和缓存预取打开；下午四点离开办公室进入弱网区域，切到通勤模式，页面自动换成紧凑摘要，图片懒加载阈值调低；晚上十一点在家打开，切到夜间模式，所有明亮背景替换成深色；投屏开会时，切到演示模式，细节表格和敏感字段全部隐藏。性能上我实测了 1000 次规则匹配，单次匹配平均耗时 0.06ms，主要开销集中在 context 快照采集。采集器的最大头是网络测速，需要发一个 1KB 的请求，耗时在几十到几百毫秒之间。我的处理方式是设置 3 秒超时，超时则标记网络为 unknown，不影响主流程。整体衡量下来，context-mode 给应用增加的开销可以忽略，但如果你的业务场景里采集器本身是重 IO 的，一定要给每个采集器单独设置超时和错误捕获。5. 常见问题与排查实录5.1 模式在临界区域反复横跳这类问题出现频率最高。地理围栏边缘、弱网阈值附近、屏幕亮度临界点，都容易让采集值不稳定。我在 3.3 节讲了防抖和最小间隔机制，这里再补充两个排查手段。第一个是看切换历史日志，确认抖动频率和周期；第二个是使用 debug 面板的快照对比功能，把临界区域内的连续快照打印出来，观察到底是哪个字段在波动。如果抖动来自某个具体字段，比如距离办公室在 280 米和 310 米之间反复，可以给这个字段加一个滞回区间：进入办公区域需要小于 280 米，离开办公区域需要大于 350 米。中间这 70 米是缓冲区，可以避免在边界处频繁切换。滞回区间本质上是模拟了硬件的滞后特性，用在软件判断里同样有效。5.2 多条规则同时匹配导致模式错乱出现过一次比较经典的案例：深夜出差、在火车上，网络质量差，系统同时匹配到通勤模式、夜间模式和标准模式。因为我在规则里写了严格的优先级，夜间模式最终胜出。但业务方反馈，用户此刻更需要的不是深夜主题，而是弱网下的精简内容，于是我把通勤模式的优先级调高了 5 档，问题就解决了。这个案例说明一个原则：优先级排序应该反映“用户在当前场景下最核心的诉求”，而不是简单的“越特殊越优先”。在配置优先级时，我建议拉上产品、运营一起走一遍典型用户故事，把每个模式的“不可妥协点”列出来，再反推优先级顺序。技术能保证机制正确，但优先级数值本身是业务决策。5.3 规则更新后客户端不生效后来我把规则改成从远端配置中心下发，本地缓存一份。有次修改了夜间模式的生效时段，结果部分用户的客户端两三天都没生效，排查下来发现是本地缓存的 schemaVersion 没跟随配置变化。旧客户端在加载新配置时，发现版本号一致就直接沿用旧逻辑。解决办法很简单：修改规则数据时，必须同步递增 schemaVersion。并且客户端在启动、网络恢复、定时轮询三个时点都要检查版本。如果版本不一致，先清空旧规则再加载新规则，避免新旧规则混用导致匹配异常。另外要给配置下发留一个 traceId，方便问题反馈时快速定位线上版本。5.4 采集器运行异常导致整体崩溃最初每个采集器的错误都没捕获，结果某个客户端环境里 presentationSource 抛了个异常，整个引擎直接瘫痪，所有模式切换失效。后来我给引擎的采集循环加了两层保护：每个采集器单独包 try/catch，单点失败只把对应字段标记为 unknown，不影响其他字段；采集器的总时间预算控制在 300ms 内，超时的采集任务直接跳过。这个设计让我避免了大量“环境相关”的兼容性问题。浏览器、WebView、桌面壳子的 API 支持程度千差万别，没有容错的话，任何一个小环境不支持都会让整个功能废掉。这里有个小技巧，注册采集器时可以传入一个 feature 检测结果，只注册当前环境支持的采集器，比运行时的 try/catch 更前置，省去了无谓的调用开销。5.5 调试技巧备忘我把这段时间积累的调试技巧整理成一个速查表：现象首查位置常见根因模式不切换事件总线日志采集器未启动、规则 condition 未通过模式频繁切换切换历史记录缺少滞回区间或最小间隔过短规则更新无效schemaVersion本地缓存覆盖了远端新配置模式匹配符合预期但 UI 没变分发回调注册情况业务组件未订阅引擎事件或订阅被重复卸载新增采集器后整体变卡采集耗时面板采集器没有超时控制或引入了同步请求debug 面板显示 unknown 字段采集器错误捕获日志当前环境 API 不支持采集器注册调试的核心思路永远是先看数据、再看规则、最后看渲染。context-mode 的事件总线把这三级信息全串起来了，只要哪个环境出现了模式异常，打开 debug 面板就能定位到是快照字段不对、规则判错还是 UI 没订阅。这比对着界面猜瞎找要高效得多。我个人实际开发中还有一个体会：规则引擎这类东西，写起来不难，真正难的是让业务方对“自动决策”建立信任。而建立信任的关键，就是给每一次决策都提供清晰的解释和回退出口。context-mode 的价值不在于把模式切换自动化，而在于把“用户感知不到切换原因”这件事彻底解决掉。后续如果你想继续扩展，可以考虑加入更丰富的上下文源，比如日历事件、心率传感器、环境噪音等，也可以把规则引擎搬到服务端，做成一套通用策略下发平台。技术骨架已经在这里，剩下的就看你能把这个上下文世界拼到多大了。
最早让我决定做一个 context-mode 项目，是因为一个特别具体的痛点：同一套应用，放在办公室、通勤路上、家里、深夜加班这些不同场景里，使用者的操作习惯和真实需求完全不一样。白天在公司网络下打开后台，你可能希望默认加载完整数据表格；到了晚上用手机流量访问，你可能只想快速看一个核心指标；开会时屏幕被投出来，你反而希望隐藏所有敏感字段。过去这些都得靠用户手动切主题、切视图、切功能开关，做多了用户烦，也根本记不住。我当时就在想，能不能让应用自己感知出“现在处于什么上下文”，然后主动切换到对应的模式。这就是 context-mode 的由来。这个项目本质上是一个“上下文感知的模式切换引擎”。它做的事情很简单：把环境信息、设备信息、时间信息、网络信息等采集起来，通过一组可配置的规则实时判断当前应该处于哪种模式，然后自动完成界面、行为、权限策略的切换。它适合的范围很广：前端页面、客户端工具、内部管理系统、甚至物联网边缘设备上都用得到。对于写过一段时间业务系统、开始被各种“环境适配”问题折磨的开发者来说，这是一个可以直接参考的方案。1. 项目背景与核心价值拆解1.1 为什么常规的“用户设置”模式不够用大多数应用目前的模式切换都靠用户主动操作，比如手动切换夜间模式、手动切换“简洁视图”。这套做法在小功能上没问题，但一旦模式的数量变多，问题就来了。第一个问题是记忆负担，用户根本不知道这个系统支持多少种模式，更不知道当前状态下用哪个模式最合适。第二个问题是切换成本，移动端随手切一下还好，后台系统里找设置项可能要点三四层菜单。第三个问题是错失时机，午夜还在写报告的用户不会想起来去开夜间模式，地铁上刚打开弱网环境的用户不会主动去关高清图片加载。这三个问题的根源是一致的：用户当前的上下文已经包含足够多的判断信息，但应用没有读取它们。时间、地理位置、网络类型、设备电量、屏幕亮度、当前日历事件，这些都是现成的上下文数据，完全可以组合起来推断出用户意图。context-mode 的出发点就是把这部分信号利用起来，让系统主动服务，而不是等待用户发号施令。1.2 核心解决的问题与基本盘这个项目解决的核心问题可以拆成四个层次。最底层是上下文采集，把分散在浏览器、客户端、传感器中的零散数据统一成结构化快照。往上一层是规则匹配，把业务人员能理解的各种判断条件翻译成可执行的匹配逻辑。再往上是模式切换，保证模式变化是平滑的、可回退的、不会来回抖动。最上层是运营能力，要让非开发人员也能通过配置中心调整规则，而不是每次改规则都发一次版本。这四个层次里，前两个是技术核心，后两个是工程落地关键。很多类似方案在 demo 阶段跑得很顺，一上生产就出问题，基本都是栽在后两层：模式切换乱跳、规则配置不灵活、出了问题不知道如何排查。所以 context-mode 在设计时就把“可观测性”和“防抖机制”当作一等公民，而不是后期补丁。1.3 适用场景与目标使用者画像如果你是做前端应用的，它可以让同一套页面在不同环境下自动调整布局、主题、数据加载策略。如果你在做客户端工具，它可以根据用户是在开会、在演示、还是在远程调试，自动切换功能可见性和通知策略。如果你在维护内部管理系统，它能帮你在投屏场景下自动隐藏敏感栏位，在公司网络环境下自动开启大文件缓存。具体来说，适合读这篇文章的人包括这么几类：被“不同环境不同行为”折磨的业务前端开发者；正在设计规则引擎、又不想从零写一套的架构师；以及那些做 IoT 网关、需要根据时段和网络状态调整上报策略的嵌入式开发朋友。后面我讲的实现思路不绑定具体框架，核心逻辑都是通用的。2. 整体架构设计：从上下文采集到模式切换2.1 设计目标与核心取舍我在动手之前定了四个设计目标，这四点影响了后续所有决策。第一是采集层必须可插拔，不能让业务代码与具体 API 强耦合，比如今天用浏览器的 Network Information API，明天换客户端的原生上报，采集器应该只是实现同一个接口的不同插件。第二是匹配规则必须数据驱动，规则的增删改不能靠改代码完成，要能序列化成 JSON、能中心化下发。第三是模式切换必须可控，绝不能出现“1 秒内切换 20 次”的抖动情况，必须有防抖、有最小间隔、有回退策略。第四点很多人会忽略，就是匹配过程必须无副作用。匹配引擎只负责算出一个“建议模式”，真正执行切换的是分发器。把这两个阶段分开之后，测试变得非常简单：你可以不看界面，直接构造上下文快照喂给匹配器，断言它输出的是哪个模式。我实际开发中体会很深，一旦匹配和执行耦合在一起，每次调试都要刷新页面、点击操作、观察变化，效率非常低。2.2 上下文快照的数据结构所有采集器最终都把数据汇总成一个上下文快照，这是一个纯普通对象，不包含任何方法，方便序列化和比较。我定义的数据结构大致是这样：interface ContextSnapshot { timestamp: number; time: { hour: number; // 0-23 weekday: number; // 0-6，0 表示周日 isWorkday: boolean; }; network: { kind: 'wifi' | 'cellular' | 'ethernet' | 'none' | 'unknown'; downlinkMbps?: number; // 实测下行速度，可缺省 isSlow: boolean; // 是否低于定义的低速阈值 }; location: { kind: 'office' | 'home' | 'transit' | 'unrecognized'; distanceToOffice?: number; // 米，可缺省 }; device: { batteryPercent: number; // 0-100，-1 表示未知 screenBrightness: number; // 0-1 isPresenting: boolean; // 是否检测到投屏/外接显示 pointerType: 'fine' | 'coarse'; // 鼠标还是触屏 }; app: { foreground: boolean; lastActiveAt: number; }; }为什么用扁平结构而不是嵌套分类？因为规则匹配的时候经常要做跨维度判断，比如“晚上九点且电量低于 20%”，扁平结构在规则函数里写起来最顺手。这个结构不是一次定死的，随着业务增加字段就好，但要注意兼容性：新增字段不能破坏旧规则，所以规则引擎里对字段访问必须做容错，默认给中性的值。2.3 模式规则模型与匹配优先级规则是 context-mode 里最核心的抽象。我设计成每条规则都不直接写死“等于某个模式”，而是包含条件、模式、优先级、权重、有效期这些字段：interface ModeRule { id: string; mode: string; // 命中的模式名称 priority: number; // 模式级优先级，数字越大越优先 condition: (ctx: ContextSnapshot) => boolean; weight: Record<string, number>; // 可选的打分项 expiresAt?: number; // 过期时间戳，默认 0 表示长期有效 }条件函数返回布尔值，是最简单直白的判断。打分机制是为了处理那些“多个条件都没完全命中，但部分信号很强”的场景。比如“深夜”和“低电量”两个条件，任何一个单独出现都不足以断定用户需要省电模式，但两个同时出现时，系统可以通过加权得分超过阈值，切到省电模式。模式之间的冲突处理我用两级策略。第一级用 priority，只保留命中规则里优先级最高的。第二级是对相同优先级的规则做加权求和，谁的得分高谁生效。如果所有规则都没命中，就返回默认模式。这套规则在设计时就要想清楚，不然线上会出现不可预测的“随机模式”。2.4 架构分层与模块边界整个项目我分成四个模块，模块之间依赖方向是单向的，不允许反向调用。采集端（source）：负责从不同数据源拿原始数据，转换成上下文快照的局部字段。引擎端（engine）：接收完整快照，执行规则匹配，产出建议模式。分发端（dispatcher）：监听引擎输出，处理防抖、持久化、用户覆盖，然后回调业务层。配置端（config）：维护规则列表、默认模式、阈值参数，支持本地或远端下发。依赖单向的好处有两个。一个是调试时随时可以用一个假快照替换真实采集端，完全不影响引擎和分发器。另一个是多个业务模块可以共用同一个引擎实例，保证规则的一致性。我试过在某个模拟项目里同时让页面主题、通知策略、数据预取开关三处消费同一个模式，正是因为共用一个引擎，才没有出现各切各的错乱情况。3. 核心实现细节：匹配引擎与切换机制3.1 采集器：如何做可插拔的设计每个采集器最简单粗暴的实现就是一个函数：负责把系统环境的信息读取出来，做归一化，写回快照对应的字段。我在项目里写了一个 Source 接口：interface ContextSource { key: string; // 例如 'time', 'network', 'location' collect(): Partial<ContextSnapshot>; destroy?(): void; // 需要清理监听器时使用 }在实现网络状态采集器时，浏览器里最直接的是 Network Information API，可以拿到 downlink 和 effectiveType。但这个 API 的语义在不同内核里并不完全一致，有的浏览器 downlink 返回的是理论值，有的返回的是估算值。所以我并不直接拿它当“低速”判断依据，而是结合一个简单的测速样本：拉取一个小的静态资源，记录耗时时长，再把两个信号融合。实测下来，用“理论值 + 实测样本”双信号判断低速，比单用任何一个都稳。采集器的注册使用简单工厂模式。引擎启动时调用 registerSource() 把各个采集器挂上去，引擎会按注册顺序依次执行，最后合成一份完整快照。销毁时会有清理逻辑，防止在 React StrictMode 或客户端热更新场景下重复注册导致监听器泄漏。3.2 规则匹配算法：条件过滤、加权评分、优先级仲裁匹配过程的代码风格偏函数式，核心思路是三步走：function matchMode(ctx: ContextSnapshot, rules: ModeRule[]): MatchResult { const activeRules = rules .filter(rule => rule.expiresAt && rule.expiresAt > Date.now() ? false : true) .map(rule => ({ rule, pass: rule.condition(ctx) })); const matched = activeRules.filter(item => item.pass); if (matched.length === 0) { return { mode: config.defaultMode, reasons: [], confidence: 0 }; } // 同一模式内算加权总分 const scored = matched.reduce((acc, item) => { const mode = item.rule.mode; const score = Object.entries(item.rule.weight || {}) .reduce((sum, [key, w]) => sum + (ctx[key] ? w : 0), 0); if (!acc.has(mode) || score > acc.get(mode).score) { acc.set(mode, { score, priority: item.rule.priority }); } return acc; }, new Map()); // 模式间按优先级仲裁 let bestMode = config.defaultMode; let bestPriority = -Infinity; for (const [mode, info] of scored) { if (info.priority > bestPriority) { bestMode = mode; bestPriority = info.priority; } } return { mode: bestMode, reasons: matched.map(item => item.rule.id), confidence: bestPriority }; }条件规则我建议写成“单独的小布尔函数”而不是一大段表达式。比如 isNightAtHome(ctx)、isWeakNetwork(ctx)、isWorkMeeting(ctx)，每个函数只判断一件事。这样规则配置可视化时，可以直接用“且 / 或 / 非”组装，也便于测试覆盖率统计。真要把复杂业务规则堆进一个函数里，后期新同学接手会非常想骂人。3.3 分发器：防抖、最小间隔和回退策略刚开始做 context-mode 时，最不满意的地方就是模式抖动。地理位置在办公室边界附近时，location 采集器一会返回 office、一会返回 unrecognized，结果模式在“工作模式”和“标准模式”之间疯狂切换。不加控制的话，界面主题就会不停跳动，用户观感极差。后来我加了三个机制。第一个是去抖等待，引擎算出一个新建议模式后，不立刻执行，而是先放进一个 pending 状态，等待 800ms 内不再出现新建议才提交。第二个是最小切换间隔，即使连续两个建议模式不同，也必须距离上一次切换超过 1.2 秒才允许再次切换。第三个是粘性偏好，如果新建议模式的置信度不比当前模式高出一个阈值，继续保持当前模式。这三个机制组合在一起，效果很明显。我在模拟项目里反复横跳地切换网络状态，最终日志显示面积最小的切换间隔也有 1.4 秒，界面完全不会出现闪烁感。需要注意的是，防抖不是越长越好，过长的去抖会让用户的真实操作被延迟响应，所以我建议把默认值控制在 800ms 到 1500ms 之间，并且支持按模式单独配置。3.4 用户覆盖与持久化策略自动模式再准，也要给用户一个“手动说了算”的出口。我在设计里专门加了一个手动覆盖层，用户一旦手动选择某个模式，系统就把它写入 localStorage（或者客户端的本地配置库），并且附带一个过期时间。过期之前的匹配流程会先检查覆盖层，有覆盖就用覆盖值，不再做自动判断。这个设计有几个细节值得分享。过期时间默认 4 小时，这样用户临时想在某个场合固定使用某个模式，不会一直固定到天荒地老；如果用户希望“本次启动内始终使用”，可以将过期时间设为 0，代表不自动过期。覆盖层必须与规则引擎隔离，不能把覆盖值混入上下文快照，否则会导致规则调试时数据源不干净。持久化数据的版本我也做了处理。规则配置会带一个 schemaVersion，本地缓存如果发现版本不匹配，会把过期的模式和规则一并丢弃，回退到默认配置。这个机制很关键，否则线上升级规则之后，老用户的本地还是会用旧逻辑跑很长时间。3.5 调试与可视化面板做规则引擎最容易遇到的问题就是“看不见”内部的决策过程。我特意在 context-mode 里内置了一个 debug 模式，它会开启一个事件总线，把每次匹配的完整链路发出去：原始快照有哪些字段、哪些规则被加载、哪些条件判定通过、最终模式从几个候选中胜出。在开发版里，我加了一个悬浮的小面板，展示当前快照、当前模式、匹配耗时、切换历史。真正上线之前直接打包关闭即可，不会留任何额外依赖。这个面板帮我在开发阶段省了大量时间，因为 UI 上的一个模式表现可能来自多层的规则组合，没有决策链路的话，排查效率极低。4. 实操环节：接入一个真实应用并跑通四种模式4.1 项目初始化与依赖选择接下来我用一个实际接入过程，演示从零开始跑通 context-mode。模拟的场景是一个企业内部的数据看板，我给它起名叫“模拟项目X”。这个看板需要支持四种模式：办公模式、通勤模式、夜间模式、演示模式。先初始化一个 Vite + React 的空项目，然后安装 context-mode 的核心包和 React 绑定包，整体依赖非常轻，核心包本身没有第三方运行时依赖。安装完成之后，在入口文件里初始化引擎、注册采集器、启动监听。import { createEngine } from 'context-mode'; import { timeSource } from 'context-mode/sources/time'; import { networkSource } from 'context-mode/sources/network'; import { geoSource } from 'context-mode/sources/geo'; import { presentationSource } from 'context-mode/sources/presentation'; const engine = createEngine({ defaultMode: 'standard', debounceMs: 800, minSwitchInterval: 1200, }); engine.registerSource(timeSource()); engine.registerSource(networkSource({ slowThresholdMbps: 1.2 })); engine.registerSource(geoSource({ officeRadiusMeters: 300 })); engine.registerSource(presentationSource()); engine.start();每个 source 的初始化函数我都配置了明确的参数。networkSource 的 slowThresholdMbps 设为 1.2，低于这个值就认为网络弱；geoSource 的 officeRadiusMeters 设为 300，距离办公室 300 米内才识别为办公地点。这些阈值不是拍脑袋定的，我是结合业务实际测量过的：公司周边三百米内信号稳定在 WiFi 覆盖区，超过这个范围就容易走蜂窝网络。4.2 定义四条模式规则规则在这个接入方案里写成一个单独的 rules.ts，方便后面接入配置中心时替换。const isOfficeTime = (ctx) => ctx.time.isWorkday && ctx.time.hour >= 9 && ctx.time.hour <= 18; const isLateNight = (ctx) => ctx.time.hour >= 22 || ctx.time.hour <= 5; const isInOffice = (ctx) => ctx.location.kind === 'office'; const isWeakNetwork = (ctx) => ctx.network.isSlow; const rules: ModeRule[] = [ { id: 'rule-office-time', mode: 'office', priority: 30, condition: (ctx) => isOfficeTime(ctx) && isInOffice(ctx), }, { id: 'rule-commute', mode: 'commute', priority: 25, condition: (ctx) => isWeakNetwork(ctx) && !isInOffice(ctx), weight: { 'ctx.network.isSlow': 10, 'ctx.time.isWorkday': 5 }, }, { id: 'rule-night', mode: 'night', priority: 35, condition: (ctx) => isLateNight(ctx), }, { id: 'rule-presentation', mode: 'presentation', priority: 40, condition: (ctx) => ctx.device.isPresenting, }, ];注意 rule-night 的优先级是 35，比 rule-office-time 高。这样即使深夜还在办公室加班，系统也会偏向夜间模式，优先照顾视觉舒适度；而演示模式的优先级最高，因为投屏场景是临时且强意图的，一旦检测到，其他所有模式都得让位。4.3 在 React 组件里消费模式变化React 侧我封装了一个 useMode() 钩子，内部订阅引擎的模式变化事件，并在卸载时取消订阅。function useMode(): string { const [mode, setMode] = useState(engine.getCurrentMode()); useEffect(() => { const unsubscribe = engine.subscribe((m) => setMode(m)); return unsubscribe; }, []); return mode; } function DashboardLayout() { const mode = useMode(); const themeClass = { office: 'theme-office', commute: 'theme-commute', night: 'theme-night', presentation: 'theme-presentation', standard: 'theme-standard', }[mode]; const showMetrics = mode !== 'presentation'; const heavyLoaded = mode === 'office'; return ( <div className={themeClass}> {showMetrics && <MetricsBoard />} {heavyLoaded && <DetailTable />} {mode === 'commute' && <CompactSummary />} {mode === 'night' && <NightOverlay />} </div> ); }这段代码里的关键点在于，模式变化时同一份数据可以驱动 UI 层和业务层同时变化。比如 showMetrics 控制敏感模块是否渲染，heavyLoaded 控制是否发起重数据请求，themeClass 控制视觉风格。整个接入过程中，我没有在业务组件里写过任何 if (new Date().getHours() > 22) 这类判断，全部收敛到模式层。4.4 实测结果与性能开销把这个接入方案跑起来之后，我观察了一组真实行为：白天在办公室打开看板，自动切到办公模式，完整表格和缓存预取打开；下午四点离开办公室进入弱网区域，切到通勤模式，页面自动换成紧凑摘要，图片懒加载阈值调低；晚上十一点在家打开，切到夜间模式，所有明亮背景替换成深色；投屏开会时，切到演示模式，细节表格和敏感字段全部隐藏。性能上我实测了 1000 次规则匹配，单次匹配平均耗时 0.06ms，主要开销集中在 context 快照采集。采集器的最大头是网络测速，需要发一个 1KB 的请求，耗时在几十到几百毫秒之间。我的处理方式是设置 3 秒超时，超时则标记网络为 unknown，不影响主流程。整体衡量下来，context-mode 给应用增加的开销可以忽略，但如果你的业务场景里采集器本身是重 IO 的，一定要给每个采集器单独设置超时和错误捕获。5. 常见问题与排查实录5.1 模式在临界区域反复横跳这类问题出现频率最高。地理围栏边缘、弱网阈值附近、屏幕亮度临界点，都容易让采集值不稳定。我在 3.3 节讲了防抖和最小间隔机制，这里再补充两个排查手段。第一个是看切换历史日志，确认抖动频率和周期；第二个是使用 debug 面板的快照对比功能，把临界区域内的连续快照打印出来，观察到底是哪个字段在波动。如果抖动来自某个具体字段，比如距离办公室在 280 米和 310 米之间反复，可以给这个字段加一个滞回区间：进入办公区域需要小于 280 米，离开办公区域需要大于 350 米。中间这 70 米是缓冲区，可以避免在边界处频繁切换。滞回区间本质上是模拟了硬件的滞后特性，用在软件判断里同样有效。5.2 多条规则同时匹配导致模式错乱出现过一次比较经典的案例：深夜出差、在火车上，网络质量差，系统同时匹配到通勤模式、夜间模式和标准模式。因为我在规则里写了严格的优先级，夜间模式最终胜出。但业务方反馈，用户此刻更需要的不是深夜主题，而是弱网下的精简内容，于是我把通勤模式的优先级调高了 5 档，问题就解决了。这个案例说明一个原则：优先级排序应该反映“用户在当前场景下最核心的诉求”，而不是简单的“越特殊越优先”。在配置优先级时，我建议拉上产品、运营一起走一遍典型用户故事，把每个模式的“不可妥协点”列出来，再反推优先级顺序。技术能保证机制正确，但优先级数值本身是业务决策。5.3 规则更新后客户端不生效后来我把规则改成从远端配置中心下发，本地缓存一份。有次修改了夜间模式的生效时段，结果部分用户的客户端两三天都没生效，排查下来发现是本地缓存的 schemaVersion 没跟随配置变化。旧客户端在加载新配置时，发现版本号一致就直接沿用旧逻辑。解决办法很简单：修改规则数据时，必须同步递增 schemaVersion。并且客户端在启动、网络恢复、定时轮询三个时点都要检查版本。如果版本不一致，先清空旧规则再加载新规则，避免新旧规则混用导致匹配异常。另外要给配置下发留一个 traceId，方便问题反馈时快速定位线上版本。5.4 采集器运行异常导致整体崩溃最初每个采集器的错误都没捕获，结果某个客户端环境里 presentationSource 抛了个异常，整个引擎直接瘫痪，所有模式切换失效。后来我给引擎的采集循环加了两层保护：每个采集器单独包 try/catch，单点失败只把对应字段标记为 unknown，不影响其他字段；采集器的总时间预算控制在 300ms 内，超时的采集任务直接跳过。这个设计让我避免了大量“环境相关”的兼容性问题。浏览器、WebView、桌面壳子的 API 支持程度千差万别，没有容错的话，任何一个小环境不支持都会让整个功能废掉。这里有个小技巧，注册采集器时可以传入一个 feature 检测结果，只注册当前环境支持的采集器，比运行时的 try/catch 更前置，省去了无谓的调用开销。5.5 调试技巧备忘我把这段时间积累的调试技巧整理成一个速查表：现象首查位置常见根因模式不切换事件总线日志采集器未启动、规则 condition 未通过模式频繁切换切换历史记录缺少滞回区间或最小间隔过短规则更新无效schemaVersion本地缓存覆盖了远端新配置模式匹配符合预期但 UI 没变分发回调注册情况业务组件未订阅引擎事件或订阅被重复卸载新增采集器后整体变卡采集耗时面板采集器没有超时控制或引入了同步请求debug 面板显示 unknown 字段采集器错误捕获日志当前环境 API 不支持采集器注册调试的核心思路永远是先看数据、再看规则、最后看渲染。context-mode 的事件总线把这三级信息全串起来了，只要哪个环境出现了模式异常，打开 debug 面板就能定位到是快照字段不对、规则判错还是 UI 没订阅。这比对着界面猜瞎找要高效得多。我个人实际开发中还有一个体会：规则引擎这类东西，写起来不难，真正难的是让业务方对“自动决策”建立信任。而建立信任的关键，就是给每一次决策都提供清晰的解释和回退出口。context-mode 的价值不在于把模式切换自动化，而在于把“用户感知不到切换原因”这件事彻底解决掉。后续如果你想继续扩展，可以考虑加入更丰富的上下文源，比如日历事件、心率传感器、环境噪音等，也可以把规则引擎搬到服务端，做成一套通用策略下发平台。技术骨架已经在这里，剩下的就看你能把这个上下文世界拼到多大了。