企业官网建设流程全解析

1. 从"context-mode"这个命名说起：它到底在解决什么问题

第一次看到context-mode这个词，我的直觉是：这大概率不是一个具体的框架或库的名字，而是一种设计模式或者运行模式的命名。在软件工程里，凡是带-mode后缀的概念，通常都意味着"同一套系统在不同条件下切换不同的行为策略"。比如我们熟悉的strict-mode、dark-mode、incognito-mode，本质上都是在描述"系统在特定上下文下应该怎么表现"。

那context-mode的核心含义就呼之欲出了：让程序根据当前所处的上下文（context），动态决定自己的行为模式。这个上下文可以是运行环境（浏览器/Node/移动端）、用户状态（登录/未登录/VIP）、数据规模（小数据量/大数据量）、调用链路（同步/异步/流式），甚至是业务场景（编辑态/预览态/只读态）。

为什么这个概念值得单独拿出来聊？因为绝大多数项目在早期都会犯一个通病：把所有场景当成一种场景来处理。代码里到处是if (isMobile)、if (isProd)、if (user.isAdmin)这种散落各处的判断，最后没人说得清系统到底有几种运行状态。context-mode这个思路的价值就在于，它把这些隐式的、散落的判断，收敛成一套显式的、可枚举的、可测试的模式集合。

我举个特别接地气的例子。你做一个表单组件，它在"新建"和"编辑"两种场景下的行为其实差别很大：新建时字段全空、提交走 POST；编辑时字段要回填、提交走 PUT、部分字段可能只读。很多人的做法是在组件内部写一堆props.isEdit的判断。而context-mode的做法是：定义create和edit两个模式，每个模式对应一套完整的配置（初始值来源、提交方法、字段权限、校验规则），组件只负责根据当前模式渲染。这样代码的可读性和可维护性完全不是一个量级。

这篇文章我会从命名背后的设计哲学、模式枚举的落地方式、上下文探测的常见坑、模式切换时的状态管理、以及真实项目里的取舍经验几个角度，把context-mode这个思路彻底讲透。不管你是做前端组件、后端服务还是全栈项目，这套思路都能直接套用。文章里涉及的具体代码我会用 TypeScript 和 JavaScript 举例，但核心思想是语言无关的。

2. 模式枚举：把"隐式判断"变成"显式契约"

2.1 为什么不能继续用布尔值堆叠

先说说为什么我不推荐用一堆布尔值来表达模式。假设一个页面有这些状态：是否登录、是否管理员、是否移动端、是否首次访问。四个布尔值理论上能组合出 16 种状态，但实际业务里可能只有 3 种是合法的。问题来了：布尔值组合无法表达"哪些组合是非法的"。

我见过一个真实的排查场景：某个按钮在"管理员 + 移动端 + 非首次访问"的组合下会报错，因为开发时只考虑了"管理员 + 桌面端"。如果用布尔值，你得写四层嵌套判断才能覆盖；如果用模式枚举，你只需要定义admin-mobile-returning这一个模式，然后明确它是否支持该操作。非法组合在类型层面就被排除了。

// 不推荐：布尔值堆叠，组合爆炸且无法表达非法状态 type PageState = { isLoggedIn: boolean; isAdmin: boolean; isMobile: boolean; isFirstVisit: boolean; }; // 推荐：模式枚举，合法状态一目了然 type PageMode = | 'guest-desktop' | 'guest-mobile' | 'user-desktop' | 'user-mobile' | 'admin-desktop' | 'admin-mobile';

2.2 模式的定义应该包含哪些维度

一个完整的模式定义，我通常会拆成四个维度：触发条件（什么情况下进入这个模式）、能力集合（这个模式下允许做什么）、数据来源（初始数据从哪来）、副作用策略（提交、跳转、埋点怎么走）。

拿一个内容编辑器的场景举例。它可能有draft（草稿）、published（已发布）、archived（归档）三种模式。草稿模式下自动保存间隔是 5 秒、允许删除；已发布模式下自动保存关闭、删除需要二次确认、修改会生成新版本；归档模式下全部只读、只能恢复。把这些写成一个配置对象，比散落在各处的if清晰太多。

const MODE_CONFIG = { draft: { autoSaveInterval: 5000, canDelete: true, deleteConfirm: false, readOnly: false, submitMethod: 'POST', }, published: { autoSaveInterval: 0, canDelete: true, deleteConfirm: true, readOnly: false, submitMethod: 'PUT', versioned: true, }, archived: { autoSaveInterval: 0, canDelete: false, deleteConfirm: false, readOnly: true, submitMethod: null, }, } as const;

提示：模式配置对象一定要用as const或者Object.freeze冻结，避免运行时被意外修改。我踩过一次坑，某个中间件偷偷改了配置对象，导致所有实例的行为都变了，排查了大半天。

2.3 模式与状态的区别：别把两者混为一谈

这里有个特别容易混淆的点：模式（mode）和状态（state）不是一回事。模式是"系统当前处于哪种运行策略"，状态是"系统当前的数据快照"。模式切换会改变行为规则，状态变化只是数据变了。

举个例子，一个视频播放器。playing/paused/buffering是状态，而normal/theater（影院模式）/mini（小窗模式）是模式。你在播放状态下可以切到影院模式，在暂停状态下也可以切到影院模式。模式决定了 UI 布局和控制条的显隐规则，状态决定了播放进度和按钮图标。

把这两个概念分开之后，代码结构会清晰很多：模式相关的逻辑放在一个modeManager里，状态相关的逻辑放在stateStore里，两者通过事件通信。我见过太多项目把这两者揉在一起，最后isPlaying && isTheater && !isBuffering这种判断满天飞。

3. 上下文探测：模式是怎么被"识别"出来的

3.1 探测来源的优先级设计

模式不会自己冒出来，得有人告诉系统"现在是什么上下文"。探测来源通常有这么几类：URL 参数、用户配置、设备特征、运行时环境变量、接口返回。关键问题是：当多个来源冲突时，听谁的？

我的经验是定一个明确的优先级，从高到低一般是：显式用户操作 > URL 参数 > 用户持久化配置 > 设备特征 > 环境默认值。为什么用户操作优先级最高？因为用户刚刚点了"切换到编辑模式"，这个意图是最新鲜的，不应该被 URL 里的旧参数覆盖。

function resolveMode(sources: ModeSources): PageMode { // 优先级从高到低依次判断 if (sources.userExplicitChoice) return sources.userExplicitChoice; if (sources.urlParam) return normalizeUrlMode(sources.urlParam); if (sources.userPreference) return sources.userPreference; if (sources.device.isMobile) return 'user-mobile'; return 'user-desktop'; }

3.2 设备探测的坑：别只看屏幕宽度

设备探测是上下文识别里最容易翻车的地方。很多人判断移动端就一句window.innerWidth < 768，这在大部分情况下能用，但有几个坑：

• 平板横竖屏切换：iPad 横屏宽度超过 1024，按宽度判断会被当成桌面端，但触控交互逻辑其实更接近移动端。
• 桌面端小窗口：用户把浏览器窗口拖窄，宽度判断会误判成移动端，但鼠标交互和触控完全不同。
• 服务端渲染：SSR 时拿不到window，首屏渲染的模式可能和客户端 hydration 后不一致，导致闪烁。

我的做法是组合判断：宽度 + 触控能力 + UA 特征三者结合，并且把"是否触控优先"作为独立维度，而不是简单二分。

function detectDevice() { const hasTouch = 'ontouchstart' in window || navigator.maxTouchPoints > 0; const isNarrow = window.innerWidth < 768; const isCoarsePointer = window.matchMedia('(pointer: coarse)').matches; return { isMobile: isNarrow && hasTouch, isTablet: !isNarrow && hasTouch && isCoarsePointer, isDesktop: !hasTouch, }; }

注意：SSR 场景下，首屏一定要用一个"中性模式"渲染，等客户端挂载后再切换到真实模式。否则会出现"服务端渲染成桌面端、客户端立刻变成移动端"的布局抖动，用户体验很差。

3.3 上下文变化的监听与防抖

上下文不是一成不变的，窗口大小会变、网络状态会变、用户登录态会变。监听这些变化时，防抖是必须的。我见过 resize 事件没防抖导致模式反复切换、组件疯狂重渲染的案例。

function createContextWatcher(onChange: (ctx: Context) => void) { let timer: number | null = null; const handler = () => { if (timer) clearTimeout(timer); timer = window.setTimeout(() => { onChange(detectContext()); }, 150); }; window.addEventListener('resize', handler); window.addEventListener('orientationchange', handler); return () => { window.removeEventListener('resize', handler); window.removeEventListener('orientationchange', handler); if (timer) clearTimeout(timer); }; }

150ms 这个值是我实测下来比较平衡的：太小了防抖没效果，太大了用户能感知到延迟。当然如果你的模式切换涉及重计算，可以适当加大。

4. 模式切换时的状态迁移：最容易出 bug 的地方

4.1 切换不是"重新初始化"

模式切换最危险的心态是"切换时把状态全部重置"。这在简单场景下没问题，但在复杂场景下会丢失用户输入。比如用户在编辑模式下写了半天的内容，切到预览模式再切回来，内容没了，这绝对是灾难。

正确的做法是区分"模式相关状态"和"模式无关状态"。模式无关的状态（比如用户填的表单数据）在切换时要保留；模式相关的状态（比如当前激活的 tab、展开的面板）可以按模式各自维护一份。

type ModeState = { // 模式无关：切换时保留 shared: { formData: Record<string, unknown>; userId: string; }; // 模式相关：每个模式独立维护 perMode: Record<PageMode, Record<string, unknown>>; };

4.2 迁移函数：显式定义"从 A 到 B 要做什么"

我强烈建议为每一对模式切换定义一个迁移函数，而不是在切换的地方写一堆if。这样每个迁移逻辑都是独立的、可测试的。

const TRANSITIONS: Record<string, (state: ModeState) => ModeState> = { 'edit->preview': (state) => ({ ...state, perMode: { ...state.perMode, preview: { scrollTop: 0, renderedAt: Date.now() }, }, }), 'preview->edit': (state) => ({ ...state, perMode: { ...state.perMode, edit: { ...state.perMode.edit, cursorRestored: true }, }, }), };

用'from->to'这种字符串做 key，好处是迁移逻辑一目了然，坏处是类型安全弱一些。如果你追求类型安全，可以用模板字面量类型把 key 约束住。

4.3 切换过程中的"中间态"处理

有些模式切换不是瞬时的，中间会有一个过渡态。比如从"只读"切到"编辑"，可能需要先请求编辑权限、再拉取可编辑的字段列表。这期间用户看到的是什么？如果处理不好，会出现"界面已经变成编辑态但数据还没到"的尴尬。

我的做法是引入一个transitioning标志，在过渡期间禁用交互并显示加载态，等数据就绪后再真正切换模式。

async function switchMode(target: PageMode) { setTransitioning(true); try { const prepared = await prepareModeData(target); applyMode(target, prepared); } catch (err) { // 切换失败要回滚到原模式，不能卡在中间态 rollbackMode(); throw err; } finally { setTransitioning(false); } }

提示：切换失败一定要有回滚逻辑。我见过一个项目，模式切换请求失败后界面卡在"半编辑"状态，用户既不能编辑也不能正常查看，只能刷新页面。这种体验问题在测试时很容易被忽略，因为测试环境很少失败。

5. 真实项目里的取舍：什么时候该用，什么时候别硬套

5.1 模式数量超过 5 个就该警惕了

context-mode这套思路很好用，但有个边界：模式数量一旦超过 5 个，维护成本会指数级上升。因为模式之间的迁移路径是 N×(N-1) 条，5 个模式就是 20 条迁移逻辑，10 个模式就是 90 条，根本维护不过来。

如果你发现模式越加越多，通常说明抽象层次出了问题。这时候应该考虑分层：把模式拆成几个正交的维度，每个维度独立管理。比如"权限维度"（游客/用户/管理员）和"设备维度"（桌面/移动）本来就是正交的，没必要组合成 6 个模式，而是两个维度各自处理。

5.2 模式配置该放前端还是后端

这是个经常被问到的问题。我的判断标准是：如果模式决定了"能做什么"（权限、能力），配置应该来自后端；如果模式只决定"怎么展示"（布局、样式），配置放前端。

原因很简单：权限相关的配置如果放前端，用户可以改。而布局相关的配置放后端，会导致每次调整 UI 都要发版，效率太低。实际项目里通常是混合的：后端返回"当前用户在这个资源上允许的操作列表"，前端根据这个列表 + 本地布局配置，推导出最终模式。

5.3 测试策略：模式组合的覆盖

模式相关的代码测试，重点不是测每个模式内部逻辑，而是测模式切换的边界。我通常会写这么几类测试：

• 每个模式下的能力断言（该禁用的按钮是否禁用）
• 关键迁移路径的状态保留（切换后数据是否还在）
• 非法迁移的拒绝（比如归档模式不能直接跳到编辑模式）
• 上下文变化触发的自动切换（窗口 resize 后模式是否正确）

describe('mode transitions', () => { it('edit -> preview 保留表单数据', () => { const state = createState({ formData: { title: 'test' } }); const next = TRANSITIONS['edit->preview'](state); expect(next.shared.formData.title).toBe('test'); }); it('archived 模式禁止删除', () => { const config = MODE_CONFIG.archived; expect(config.canDelete).toBe(false); }); });

5.4 我踩过的三个坑

第一个坑是模式初始化时机。早期我把模式初始化放在组件useEffect里，结果 SSR 首屏和客户端不一致，出现闪烁。后来改成在应用入口处同步初始化，问题解决。

第二个坑是模式切换的竞态。用户快速连续切换模式，前一个切换的异步请求后返回，把后一个切换的结果覆盖了。解决办法是给每次切换打一个递增的 token，返回时校验 token 是否还是最新的。

let switchToken = 0; async function switchMode(target: PageMode) { const token = ++switchToken; const data = await prepareModeData(target); if (token !== switchToken) return; // 已被更新的切换取代 applyMode(target, data); }

第三个坑是模式配置的深拷贝。模式配置里有嵌套对象时，浅拷贝会导致不同实例共享引用，一个实例改了配置，其他实例全受影响。用structuredClone或者手写深拷贝，别偷懒用扩展运算符。

6. 把这套思路沉淀成团队规范

context-mode这套东西，一个人用是技巧，一个团队用就是规范。我在几个项目里推行过之后，总结出几条落地建议。

首先，模式定义必须集中管理。所有模式枚举、配置、迁移函数放在一个目录下，比如src/modes/，不允许散落在业务组件里。这样新人接手时能一眼看清系统有几种运行状态。

其次，模式切换必须走统一入口。禁止在业务代码里直接改模式相关的状态，所有切换都通过switchMode这个函数。这样切换时的日志、埋点、回滚逻辑才能统一处理。

最后，模式相关的 bug 要沉淀成测试用例。每次线上出现模式相关的故障，修复后必须补一个测试，防止回归。我负责的一个项目里，模式相关的测试用例从最初的 5 个涨到了 40 多个，覆盖了几乎所有踩过的坑，后来这类 bug 基本绝迹了。

这套思路说到底，核心就一句话：把系统"在什么情况下怎么表现"这件事，从隐式的、散落的判断，变成显式的、集中的契约。听起来简单，但真正做到位的项目并不多。如果你正在维护一个状态复杂、场景多样的系统，不妨从梳理现有的模式开始，哪怕先画一张"模式-能力"对照表，都会对理解系统有很大帮助。