企业官网建设流程全解析

我最早注意到"context-mode"这个词，是在一次线上事故的复盘文档里。当时我们把一套业务代码部署在双环境上，线上数据被"串"得面目全非，几个后端同事查了一整天才定位到根因——不是登录态失效，也不是数据库脏读，而是一段"想当然"的全局状态在多个上下文之间互相污染。后来我陆续在 React 服务端渲染、Node 多租户服务、浏览器自动化测试三个完全不同的领域里，反复撞见同样的东西：context-mode，不是什么框架的专属开关，而是同一套逻辑需要在多个运行环境或会话之间安全切换时，那一整套必须被显式设计出来的隔离机制。

这篇文章不打算从概念讲到概念，我想用三个我实际拆过的项目来展开：React 服务端组件与客户端组件之间的上下文切换、Node 服务端请求级上下文的隔离、以及 Playwright 自动化测试里 context 级会话管理。它们的共同点在于——默认共享很危险，显式隔离才安全，但每一条路上的坑长得完全不一样。如果你写过 SSR、维护过多租户后端，或者跑过任何 UI 自动化任务，这里的排查思路和实操细节都能直接抄到你自己项目里。

1. "context-mode"不是模式，是三套被我搞砸过的环境切换机制

先说我为什么对"context-mode"这个关键词这么敏感。它本身不是某个开源项目，也不是某项语言特性，而是一种在工程中反复出现的结构性需求：当同一份代码需要分别运行在服务端与客户端、不同租户的请求之间、不同登录态的浏览器会话里，你必须主动告诉系统"现在切换到哪一套上下文"。谁没做过这个声明，谁就等着线上翻车。

1.1 我第一次撞上这个词，是在 React 的 Server Components 里

当时我们把一个后台系统从纯客户端渲染改造成 Next.js App Router 架构。改造之前大家都有个错觉：组件就是组件，管它在哪渲染。直到我们把一个依赖window的图表组件直接引进了服务端组件树里，浏览器直接白屏，控制台才给了提示——跨组件边界传进去的某些 props 是无法序列化的。那一刻我才意识到：每个组件默认活在默认上下文里，你在服务端写了一个组件，它不会自动安全地跑到客户端。要切换上下文，需要显式的指令，需要遵守序列化规则，需要明确哪些代码只属于服务端、哪些只属于客户端。

后来我查了下，"context-mode"在很多团队里被当作"运行环境模式"的简称来用，比如 SSR/CSR 切换、普通执行与调试执行、隔离会话与共享会话。在 React 生态里，它就具体表现为"use client"和"use server"这两条边界指令。很多新手不理解为什么一行字符串标记就能决定组件的运行环境，我说个直白的关系你就懂了：它不是把组件"挪"到另一个地方，而是告诉打包器：到这里，组件的评估上下文从一套切换成另一套。服务端已经准备好的 props 只能以 JSON 可序列化的形式跨过边界，函数、类实例、Date对象（某些特殊处理后除外）都不行。谁要是把数据库连接或密钥对象塞进 props，构建阶段就会被拦截。

1.2 第二次深刻教训，在 Node 服务端请求上下文的隔离上

我们那套多租户服务，每个请求会携带租户 ID，后端要根据租户 ID 切换数据源。最初大家图省事，把"当前租户"存到一个模块级的全局变量里，再用中间件去赋值。单请求调试时一切正常，并发一上来就乱套：A 租户的账单可能查到 B 租户的订单。这个场景的"context-mode"目标非常明确——每个异步请求链路必须拥有独立的上下文，而且这个上下文要能被整个调用链任意深度地读取到。Node.js 官方的AsyncLocalStorage就是干这个的，但我见过太多团队不用它，而是用全局对象、用req参数层层传递、用闭包变量硬扛。后面我会单独用一章演示完整的排查链路，这里先记住一个结论：Node 的单线程并发模型不代表共享状态安全，恰恰相反，因为它共享同一块内存，才更容易在异步切换时踩穿隔离边界。

1.3 第三次，被浏览器自动化测试的共享会话坑到怀疑人生

项目里用 Playwright 写 E2E 测试，刚开始图快，整个测试套件只创建一个browser，所有用例共用默认页面和默认登录态。结果测试开始随机失败：上一个用例的弹窗遮住了下一个用例的按钮，上一个用例写入的 localStorage 污染了下一个用例的权限判断。后来我把每个用例改成各自创建独立的context，所有随机失败在一夜之间消失了。浏览器自动化里的browser.newContext()，就是最典型的 context-mode：同一个浏览器进程，多个相互隔离的会话环境，每个 context 有各自的 cookie、localStorage、缓存和代理设置。如果你已经写了一阵子自动化测试，看完这篇至少能少改三版测试代码。

2. 默认上下文：比显式隔离更危险的全局共享区

很多人一听到"上下文模式"，第一反应是"我用的是多租户、我在微服务、我有网关隔离，应该很安全"。但实际问题几乎总是出在你以为的上下文边界，和运行时真正的边界不一致。这一章把默认上下文的风险讲透，后面排查问题的时候你会更快定位。

2.1 "默认"的本质是共享，而共享状态是所有并发问题的温床

无论是 React 还是 Node，只要没有显式创建新上下文，代码就运行在一个全局默认环境里。服务端渲染时，多个用户请求可能同时进来，如果某个组件模块在顶层声明了let user = ...，那这个变量对所有请求开放可写——这比函数里局部变量危险得多。很多 JavaScript 经验的开发者习惯了"单线程安全"这个直觉，认为没有多线程就没有并发竞争。但你在await之后读到的变量，很可能早就被另一个请求改掉了。我说一个简单的比喻：默认上下文就像合租房里的公共冰箱，你放进自己标签的食物，也可能被别人顺手拿走；只有租下独立房间（显式上下文），你的状态才真正属于你。

为了让你直观地对比"共享"和"隔离"的差别，我整理了一个表格，这也是我排查问题时用得最多的对照框架：

当初我们线上串号的第一现场，就是一个"默认上下文"的典型案例：模块顶层声明了currentUser，中间件按请求赋值，异步处理函数里读取。两个请求在事件循环里交错执行时，后一个请求还没await完，前一个请求就又把currentUser覆盖了。这个 root cause 花了一个多小时才揪出来，因为单次调试、甚至压测的前几十秒都不会暴露问题。

2.2 为什么很多框架默认不帮你隔离，反而要你主动声明

你可能想问：既然全局共享这么危险，为什么 React 不默认把所有组件都做成客户端独立的？为什么 Node 不默认给每个请求开一个隔离宇宙？答案很简单：隔离是有成本、有复杂度代价的。服务端组件如果全部独立渲染上下文，序列化和数据传输的开销会让首屏性能急剧下降；Node 如果每个请求都复制一套完整运行时环境，内存和对象创建的消耗完全不可接受。所以工程上的平衡是：默认共享，但在需要状态隔离的关键边界上提供显式的 context-mode 机制，由工程师决定在哪里切、怎么切。

以 React 为例，App Router 的行事规则是先服务端组件为默认，只在需要交互状态时用"use client"声明客户端边界。好处是绝大多数数据获取和渲染逻辑留在服务端，避免把密钥和查询逻辑暴露给浏览器；代价是你在客户端组件里不能直接使用服务端上下文，比如直接访问数据库。这种设计逼着开发者把"上下文边界"当成一等公民来思考，而不是凭感觉写代码。

在 Node 服务端，AsyncLocalStorage也是一种"按需显式"的机制：只有你主动调用store.run()，新的异步上下文才会被创建，并且这个上下文能自动传播给后续所有异步调用。你不调用，它就和普通模块变量没有任何区别。这个"显式触发"的设计常被误读为复杂，但其实特别合理——框架不可能猜到你希望哪个请求用哪份租户数据，它只是把创建一个独立上下文的能力交给你，并用清晰的 API 保证"只要你 run 了，整条异步链都稳"。

2.3 context 泄漏的两个典型信号：偶发错乱和跨请求串扰

我总结了两个高频信号，遇到任何一个都要第一时间往 context 隔离方向查：

1. 偶发错乱：同样的入参，有时正常有时返回他人数据；单次执行永远复现不了，只有并发或长时间运行时才冒出来。这类问题 90% 是模块级可变状态被多请求共享。
2. 跨请求串扰：请求 A 的日志里出现了请求 B 的追踪 ID，或者请求 A 创建的临时标记影响到了请求 B 的业务分支。这种情况几乎可以锁定为没有正确使用异步上下文传播机制。

这两个信号在 React SSR、Node API 和自动化测试里都会出现。后面我给的排查步骤，本质就是顺着这两类信号倒推代码里的"共享点"。

3. 三个真实场景下的 context-mode 切换实践

这一章直接给可复制的实操。每个场景我都会讲清楚：在哪条边界上切换、切换的指令或 API 是什么、切换之后有哪些必须遵守的规则、以及我实际踩过的坑。

3.1 React/Next.js 渲染上下文切换："use client"与"use server"的边界艺术

在 App Router 里，组件默认是服务端组件。这意味着组件内不能直接用useState、useEffect这类客户端 Hook，也不能绑定事件处理器。如果你想做交互组件，必须显式地把组件标记为客户端组件。下面是最小可运行示例：

// app/page.tsx —— 服务端上下文 import { ProfileCard } from "./ProfileCard"; async function Page() { const user = await fetchUserFromDb(); // 服务端直连数据库 return ( <div> <h1>用户中心</h1> <ProfileCard user={user} /> </div> ); } // app/ProfileCard.tsx —— 客户端上下文 "use client"; import { useState } from "react"; export function ProfileCard({ user }: { user: { name: string } }) { const [collapsed, setCollapsed] = useState(true); return ( <button onClick={() => setCollapsed(!collapsed)}> {collapsed ? "展开" : "收起"} {user.name} </button> ); }

这个例子的核心价值在于：user是在服务端通过数据库查询拿到的，它却可以以 props 的形式传给客户端组件。能传的前提是这个对象可以被序列化——纯对象、字符串、数字、布尔值都可以。你要是试图把数据库连接实例、读文件流、或者某个类实例传下去，React 会直接抛错。这个限制不是刻意刁难，而是上下文切换的物理现实：服务端和客户端之间只是一段可序列化数据的搬运。

实操中的几个关键注意点：

• "use client"标记的是模块边界，而不是组件边界。一个文件顶部的"use client"会让该文件导出的所有组件进入客户端上下文，如果你在同一个文件里同时导出了纯展示组件和交互组件，全都变成客户端渲染，服务端优势就削弱了。我习惯的做法是按边界拆文件。
• 服务端组件可以异步，客户端组件不能（至少不能直接把 async 函数当作组件渲染）。所以需要异步数据的地方，尽量放在上层服务端组件里，把最终数据作为 props 传给客户端组件。
• 事件处理器和 Hook 只能在客户端组件中使用。我把一个用了onClick的按钮写成服务端组件时，编译直接报错，这反而是好事——编译器把上下文错误提前暴露了。
• 如果需要在客户端触发服务端逻辑，用 Server Actions，也就是在文件顶部标记"use server"。它的作用是从客户端上下文反向创建一条安全通道，通过 HTTP 把调用意图送回服务端执行，而不是把服务端能力直接暴露给客户端。

我遇到过的最隐蔽的坑：把组件标记成"use client"后，又往里导入了一个依赖process.env的工具函数。构建能通过，但浏览器执行时process并不存在，直接报未定义。正确做法是：在客户端组件里只传明文配置，不要在客户端读取服务端环境变量。这个失误让我意识到，context-mode 切换不只是语法标记，还牵涉运行环境 API 的可用性差异。

3.2 Node 服务端请求上下文隔离：用 AsyncLocalStorage 绑定请求级状态

后端多租户服务最常见的需求是：请求进来时解析出租户 ID，后续整条调用链——不管是数据库访问、日志记录、还是第三方 API 调用——都要能随时读取当前租户 ID，而不需要层层传参。AsyncLocalStorage把这个能力做得很干净：

const { AsyncLocalStorage } = require("node:async_hooks"); const requestStore = new AsyncLocalStorage(); // 中间件：每个请求开启独立异步上下文 app.use((req, res, next) => { const tenantId = parseTenantId(req); requestStore.run({ tenantId, requestId: req.id }, () => { next(); }); }); // 业务代码：任何深度都能取到当前上下文 function getTenantId() { const store = requestStore.getStore(); if (!store) throw new Error("当前不在任何请求上下文中"); return store.tenantId; } function log(message) { const store = requestStore.getStore(); console.log(`[${store?.requestId ?? "-"}] ${message}`); }

这里的关键是requestStore.run(value, callback)的语义：在 callback 执行期间，新建的异步资源会继承这个上下文值；callback 结束，上下文自动恢复。中间件只要包一个run，后续所有因这个请求产生的await操作、setTimeout、Promise 回调，都能通过requestStore.getStore()拿到同一份数据。

我用了两年这套方案后，总结出的几条实操规则：

• 必须在最外层中间件里创建上下文，任何业务逻辑之前就要run完。如果业务代码已经跑起来再创建，那你就会有一半的调用链读不到上下文。
• 尽量只存不可变数据。比如租户 ID、请求 ID。getStore()拿到的是一个引用，你往里塞可变对象，等于在一个上下文内又造了一个全局共享区，容易埋下新坑。
• 慎用ALS的enterWith()。它可以在没有回调的情况下直接设置当前上下文，但生命周期极难控制，我见过同事用它导致上下文从主请求泄漏到定时任务里的情况。默认优先用run()。

还有一个很多团队忽视的点：并不是所有异步资源都会自动关联 ALS 上下文。某些原生的 C++ 模块、部分 Worker 线程场景，不会继承主线程的 store 值。遇到这种模块，就得显式地把 context 值传入，或者用AsyncResource手动绑定。第一次遇到这种"断链"会被坑得很惨，因为日志里什么都没报，就是拿不到值。

3.3 浏览器自动化测试的 context 级隔离：每个测试一个"干净房间"

Playwright 提供了一个非常优雅的设计：一个browser可以产生多个context，每个 context 相当于一个全新的"浏览器实例"的会话环境。它有独立的 cookie、localStorage、缓存和历史记录，但共享同一个浏览器内核。它在自动化测试里的用法，就是替每个测试准备一个完全干净的隔离空间：

import { test, expect } from "@playwright/test"; test.use({ // 每个测试自动生成独立 context，也可以在这里指定 locale 等配置 locale: "zh-CN", }); test.describe("订单流程", () => { test("用户可以看到自己的订单列表", async ({ browser }) => { // 自定义 context，避免测试之间共享登录态 const context = await browser.newContext({ storageState: "auth/userA.json", }); const page = await context.newPage(); await page.goto("/orders"); await expect(page.getByText("订单号 A123")).toBeVisible(); await context.close(); }); test("退出登录后跳转首页", async ({ browser }) => { // 不设置 storageState，得到一个未登录的全新会话 const context = await browser.newContext(); const page = await context.newPage(); await page.goto("/profile"); await expect(page).toHaveURL(/login/); await context.close(); }); });

这两个测试之间的隔离是彻底的：第一个测试的登录态不会影响第二个测试；第一个测试写入 localStorage 的 token 也不会被第二个测试读到。这样每个用例的起点是确定的，你不再需要花时间清理环境。过去我们共享同一套登录态，最典型的问题是"测试顺序即结果"——把测试顺序一换，全红。

我在团队里推的规范是：每个测试要么通过storageState加载模拟登录态，要么就用全新 context 访问公开页面，绝对不共享 context。对于一些耗时较长的冒烟测试，这种隔离会带来一点内存开销，但换取的是稳定性和可排查性。你甚至可以给每个context起一个名字，方便调试时区分：

const context = await browser.newContext({ userAgent: "e2e-test" }); context.setDefaultNavigationTimeout(30_000);

如果你曾经被"测试偶发失败、重跑就过"折磨过，先把所有 context 共享的问题去掉，大概率能解决大半。

4. 一次会话串号的完整排查链路：从噪声到根因的四步定位

前面铺了这么多概念，这一章回到我最开始说的那次线上事故。把它完整还原出来，比直接给你十个结论更有价值——因为排查思路本身才是可以复用的资产。

事故描述是这样的：多租户 SaaS 后台，生产环境偶发"A 用户看到了 B 用户的下拉选项"。这个问题上报了两天，每次让用户刷新又好了，完全随机。

4.1 第一步：锁定复现条件，拒绝"刷新一下就好"

我们一开始按老思路查网络层、查中间件、查数据库权限，全部正常。但有个细节引起了我的注意：只有高并发时段才出现，微服务 1 个 Pod 独立运行时几乎不出现。这个信息很关键——它排除了数据库层面的租户隔离问题，因为数据库查询SQL都是带 tenant_id 的；问题更可能出在应用层内存里的"临时状态"。

分析方法上，我给所有请求入口加上了临时日志，记录租户 ID 和请求 URL。为了不污染线上日志，我特意把日志级别提到 debug 并只匹配特定用户，结果很快发现规律：两个并发请求进入同一个 Node 进程后，处理中途读取到的租户 ID 与请求头不一致。到这里，问题范围从"整个后台服务"缩小到了"请求上下文传播"。

4.2 第二步：画出请求处理链路，找出所有可能的状态读写点

我们的技术栈是 Express + 业务 Service 层，所有请求都走统一的中间件。我最开始猜是某个中间件设置了 header 后又把它改了，于是把整个链路画了一遍：鉴权中间件 → 租户解析中间件 → 业务 Controller → Service → 数据访问层。然后逐个排查每个环节对"当前用户/当前租户"的读写。

画链路时我发现了一段疑似问题代码——某个鉴权模块把用户对象直接挂在了模块顶层：

let currentUser = null; async function authMiddleware(req, res, next) { const user = await getUserFromToken(req); currentUser = user; // 危险：这里改的是进程级全局 req.user = user; next(); } async function getOrders(req, res) { // currentUser 在 await 期间可能已被其他请求覆盖 await syncData(); res.json(await fetchOrdersForUser(currentUser.id)); }

注意，req.user本身是安全的，它是请求对象上的属性；但currentUser是模块级变量，对所有请求共享。当getOrders执行到syncData()时发生await，事件循环让出控制权，另一个请求进来把currentUser指向前一个用户，等syncData完成后，currentUser.id就指向了别人。这就是串号的直接机制：一个跨请求共享的写读窗口。

4.3 第三步：确认根因是上下文传播断裂，而不是并发逻辑错乱

很多人会在这一步陷入"并发锁"或"事务隔离"的错误方向。我们当时的排查焦点是"为什么req.user是对的，而currentUser是错的"。画出异步执行顺序后，答案已经很明显：请求对象是上下文隔离的，模块变量不是。但要彻底排除其他嫌疑，我在测试环境写了一个脚本模拟并发：

const concurrentRequests = 50; const promises = Array.from({ length: concurrentRequests }, (_, i) => fetch("/api/orders", { headers: { Authorization: `Bearer token-${i}` }, }) ); Promise.all(promises).then((responses) => { const invalid = responses.filter((r) => r.headers.get("x-user-id") !== r.url.split("?")[1]); console.log(`invalid count: ${invalid.length}`); });

无压力跑的时候invalid是 0；加了并发之后很快就跳出了几十条。这个复现实验敲定了根因：上下文边界在模块变量处断裂了。一行let currentUser把每个请求应该独立的状态拉回到了进程级共享区。

修复方案没有悬念：把用户状态从模块全局变量迁入AsyncLocalStorage，在中间件里用requestStore.run({ user }, next)包裹，业务里通过requestStore.getStore()?.user读取。改完后跑同样的并发脚本，invalid稳定为 0。我还加了一条防御性规则：后续代码里禁止新增模块级可变状态，如果需要缓存，必须有明确的过期策略和上下文标签。

4.4 第四步：用全链路上下文日志固化防线

修好问题只是第一步。我后来把请求 ID、租户 ID、用户 ID 都放进了 ALS 上下文，日志框架会自动附带这些字段。之后排障只需要按 requestId 拉一条完整日志，就能看到这个请求从头到尾经过哪些服务、读了哪个租户的数据。这比任何微服务链路追踪工具都轻量，而且保证在单服务内绝对可靠。那次事故之后，我们团队定了一条硬规矩：任何请求级状态，禁止直接赋值给模块顶层变量；必须显式创建上下文，并在上下文内完成全部异步逻辑。

5. 把 context-mode 当作一种设计思路：四种边界策略

踩过三次坑之后，我反而觉得"context-mode"这个词值得更泛化的使用。它不是某个库的 API 名，而是一类设计思路的总称：你要在代码里明确区分哪些状态属于哪个运行环境/哪个请求/哪个会话，并主动提供边界机制。脱离具体技术栈去看，总共就四种常见策略，你可以直接拿去评估自己项目的代码。

这张表不是我拍脑袋总结的，它是我反复排查线上问题的判据。遇到任何状态异常，我会先问：这个状态属于哪个上下文？它是在上下文内创建的，还是不小心放在外层共享了？如果回答不上来，代码大概率就有隐患。

5.1 选型时的两个判断标准：独立频率与状态生命周期

不是所有场景都需要上 context 隔离。过度设计同样会拖垮项目。我总结了两条判断标准：

1. 状态独立频率：如果同一个进程/会话里，同时存在多个互相独立的实例（多个请求、多个租户、多个测试），并且它们会交错执行，那就必须隔离；如果永远只有一个实例单线程顺序跑，全局变量反而简单。
2. 状态生命周期：如果状态只在单个请求内部有意义、请求结束就该销毁，那必须绑定请求上下文；如果状态是进程级配置、创建后不变，全局只读是合理的。

举例来说，数据库连接池本身就是进程级共享的，不应该放进请求上下文；但"当前这个请求应该使用哪个数据源"则是请求级状态，必须上下文化。这两个看似相同的"数据库"，生命周期完全不同。

5.2 团队落地时的三条可执行规范

技术方案定好之后，落地才是真正的难点。我在这方面推过的规范不多，但每条都救过团队一次：

• 模块顶层只用const。任何let的可变变量，都必须能说清楚它的生命周期归属。如果它属于某个请求/会话，必须放到显式上下文里。
• 在中间件/入口处统一创建上下文。不要在业务代码里东一个run西一个run，入口统一包裹，靠框架保证传播，靠 review 保证不绕行。
• 为上下文打上可追踪的标签。至少带上 requestId、tenantId、userId 这类字段，日志埋点直接引用。排查时效会成倍提升。

如果你正在设计自己的库或框架，也可以参考这套思路：别让用户靠自觉维护上下文，而是提供入口级机制，让正确用法成为最自然的写法。React 和 Playwright 都做到了这一点，这也是它们易上手却不易出错的原因。

这套思路扩展下去还有不少可玩的空间。比如服务端微服务之间传递上下文头、前端多 Tab 的会话隔离、甚至浏览器扩展脚本里的环境切换，本质都是在回答同一个问题："当前这段逻辑，运行在哪套上下文里？"想清楚这个问题，很多偶发的灵异 bug 会消失得无影无踪。