14W 行代码量的前端页面长什么样

作者：sigmaliu，腾讯文档 AlloyTeam 开发工程师

0. 前言

腾讯文档列表页在不久前经历了一次完全重构后，首屏速度其实已经是不错。但是我们仍然可以引入 SSR 来进一步加快速度。这篇文章就是用来记录和整理我最近实现 SSR 遇到的一些问题和思考。虽然其中有一些基础设施可能和腾讯或文档强相关，但是作为一篇涉及 Node、React 组件、性能、网络、docker 镜像 、云上部署、灰度和发布等内容的文章，仍然可以小小地作为参考或者相似需求的 Checklist。

就是这样一个页面，内部逻辑复杂，优秀的重构同学做到了组件尽可能地复用，未压缩的编译后开发代码仍然有 14W 行，因此也不算标题党了。

1. 整体流程

1.1 CSR

我们回顾 CSR（客户端渲染）的流程

1. 一个 React 应用，通常我们把 CSS 放在 head，有个 React 应用挂载的根节点空标签，以及 React 应用编译后的主体文件。浏览器在加载 HTML 后，加载 CSS 和 JS，到这时候为止，浏览器呈现给用户的仍然是个空白的页面。

2. <红色箭头部分> JS 开始执行，状态管理会初始化个 store，会先拿这个 store 去渲染页面，这时候页面开始渲染元素（白屏时间结束）。但是还没有列表的详细信息，也没有头像、用户名那些信息。

3. 初始化 store 后会发起异步的 CGI 请求，在请求回来后会更新 store，触发 React 重新渲染页面，绑定事件，整个页面完全呈现（首屏时间结束）。

1.2 SSR

1. <绿色箭头部分> 首先我们复用原来的 React 组件编译出可以在 Node 环境下运行的文件，并且部署一个 Node 服务。

2. <蓝色箭头部分> 在浏览器发起 HTML 请求时，我们的 Node 服务会接收到请求。可以从请求里取出 HTTP 头部，Cookie 等信息。运行对应的 JS 文件，初始化 store，发起 CGI 请求填充数据，调用 React 渲染 DOM 节点（这里和 CSR 的差异在于我们得等 CGI 请求回来数据改变后再渲染，也就是需要的数据都准备好了再渲染）。

3. 将渲染的 DOM 节点插入到原 React 应用根节点的内部，同时将 store 以全局变量的形式注入到文档里，返回最终的页面给浏览器。浏览器在拿到页面后，加上原来的 CSS，在 JS 下载下来之前，就已经能够渲染出完整的页面了（白屏时间结束、首屏时间结束）。

4. <红色箭头部分> JS 开始执行，拿服务端注入的数据初始化 store，渲染页面，绑定事件（可交互时间结束）（这里其实后面可能还有一些 CGI，因为有一些 CGI 是不适合放在服务端的，且不影响首页直出的页面，会放在客户端上加快首屏速度。这里的一个优化点在于我们将尽量避免在服务端有串行的 CGI 存在，比如需要先发起一个 CGI，等结果返回后才发起另外一个 CGI，因为这会将 SSR 完全拖垮一个 CGI 的速度）。

2. 入口文件

2.1 服务端入口文件

要把代码在 Node 下跑起来，首先要编译出文件来。除了原来的 CSR 代码外，我们创建一个 Node 端的入口文件，引入 CSR 的 React 组件。

(async () => {
    const store = useStore();

    await Promise.all([
        store.dispatch.user.requestGetUserInfo(),
        store.dispatch.list.refreshRecentOpenList(),
    ]);

    const initialState = store.getState();
    const initPropsDataHtml = getStateScriptTag(initialState);

    const bodyHtml = ReactDOMServer.renderToString(
        
            
        
    );
		// 回调函数，将结果返回的
    TSRCALL.tsrRenderCallback(false, bodyHtml + initPropsDataHtml);
})();

服务端的 store，Provider, reducer，ServerIndex 等都是复用的客户端的，这里的结构和以下客户端渲染的一致，只不过多了 renderToString 以及将结果返回的两部分。

2.2 客户端入口文件

相应的，客户端的入口文件做一点改动：

export default function App() {
    const initialState = window.__initial_state__ || undefined;

    const store = useStore(initialState);
    // 额外判断数据是否完整的
    const { getUserInfo, recentList } = isNeedToDispatchCGI(store);

    useEffect(() => {
        Promise.race([
            getUserInfo && store.dispatch.user.requestGetUserInfo(),
            store.dispatch.notification.requestGetNotifyNum(),
        ]).finally(async () => {
            store.dispatch.banner.requestGetUserGrowthBanner();
            recentList && store.dispatch.list.requestRecentOpenList();
        });
    }, []);
}

主要是复用服务端注入到全局变量的数据以及 CGI 是否需要重发的判断。

2.3 代码编译

将服务端的代码编译成 Node 下运行的文件，最主要的就是设置 webpack 的 target: 'node' ，以及为了在复用的代码里区分服务端还是客户端，会注入编译变量。

new webpack.DefinePlugin({
    __SERVER__: (process.env.RENDER_ENV === 'server'),
})

其他的大部分保持和客户端的编译配置一样就 OK 了，一些细微的调整后面会说到。

3. 代码改造

将代码编译出来，但是先不管跑起来能否结果一致，能不报错大致跑出个 DOM 节点来又是另外一回事。

3.1 运行时差异

首先摆在我们前面的问题在于浏览器端和 Node 端运行环境的差异。就最基本的，window，document 在 Node 端是没有的，相应的，它们以下的好多方法就不能使用。我们当然可以选择使用 jsdom 来模拟浏览器环境，以下是一个 demo：

const jsdom = require("jsdom");
const { JSDOM } = jsdom;
const { window } = new JSDOM(``, {
    url: 'http://localhost',
});

global.localStorage = window.localStorage;

localStorage.setItem('AlloyTeam', 'NB');
console.log(localStorage.getItem('AlloyTeam'));

// NB

但是当我使用的时候，有遇到不支持的 API，就需要去补 API。且在 Node 端跑预期之外的代码，生成的是否是预期的结果也是存疑，工作量也会较大，因此我选择用编译变量来屏蔽不支持的代码，以及在全局环境下注入很有限的变量（vm + context）。

3.2 非必需依赖

对于不支持 Node 环境的依赖模块来说，比如浏览器端的上报库，统一的打开窗口的库，模块动态加载库等，对首页直出是不需要的，可以选择配置 alias 并使用空函数代替防止调用报错或 ts 检查报错。

alias: {
    src: path.resolve(projectDir, 'src'),
    '@tencent/tencent-doc-report': getRewriteModule('./tencent-doc-report.ts'),
    '@tencent/tencent_doc_open_url': getRewriteModule('./tencent-doc-open-url.ts'),
    'script-loader': getRewriteModule('./script-loader.ts'),
    '@tencent/docs-scenario-components-message-center': getRewriteModule('./message-center.ts'),
    '@tencent/toggle-client-js': getRewriteModule('./tencent-client-js.ts'),
},

例如里面的 script-loader（模块加载器，用来动态创建 `; } export function getStateScriptTag(initialState: any) {     return injectDataToClient('__initial_state__', initialState); };

3.12 服务端路由

对于单页面来说，使用 react-router 来管理路由，服务端也需要直出相对于的组件。需要做的只是将路由组件换成 StaticRouter ，通过 localtion提供页面地址和 context 存储上下文 。

import { StaticRouter as Router } from 'react-router-dom';

(async () => {
    const routerContext = {};

    const bodyHtml = ReactDOMServer.renderToString(
        
            
                
            
        
    );
})();

4. 运行环境

4.1 网络

4.1.1 网络请求

当浏览器发起 CGI 请求，形如 https://docs.qq.com/cgi-bin/xxx，不仅需要解析 DNS，还需要建立 HTTPS 链接，还要再经过公司的统一网关接入层。如果我们的 SSR 服务同部署在腾讯云上，是否有请求出去绕一圈再绕回来的感觉？因为我们的服务都接入了 L5（服务发现和负载均衡），那么我们可以通过解析 L5 获得 IP 和端口，以 HTTP 发起请求。

以兼容 L5 的北极星 SDK 来解析（cl5 需要依赖环境，在我使用的基础镜像 tlinux-mini 上会有错误）。

PS: Axios 发送 HTTPS 请求会报错，因此在 Node 端换成了 Got，方便本地开发。

const { Consumer } = require('@tencent/polaris');
const consumer = new Consumer();

async function resolve(namespace, service) {
    const response = await consumer.select(namespace, service);

    if (response) {
        const {
            instance: { host, port },
        } = response;

        return `${host}:${port}`;
    }

    return null;
}

需要注意的是，北极星的第一次解析比较耗时，大概 200ms 的样子，因此应该在应用启动的时候就调用解析一次，后续再解析就会是 1~3ms 了。

这里还有个点是我们应该请求哪个 L5？假设有两个 CGI，doclist 和 userInfo，我们是解析它们各自的 L5，通过 OIDB 的协议请求吗？考虑三个方面：

1. 这里询问了文档后台，通过 OIDB 并没有比通过 HTTP 协议快多少；

2. 我们需要一直维护 CGI 和 L5 的对应关系，如果后台重构，信息同步不到位，换了新的 L5，服务将会挂掉；

3. 没有更新 xsrf 的逻辑；

好在文档还有个统一的接入层 tsw，因此我们其实只需要解析接入层 tsw 的 L5，将请求都发往它就可以了。

4.1.2 cookie

在 SSR 代发起 CGI 请求，不仅需要从请求取出客户端传递过来的 cookie 来使用，在我们的 tsw 服务上，还会验证 csrf，因此 SSR 发出 CGI 请求后，可能 tsw 会更新 csrf，因此还需要将 CGI 请求返回的 set-cookie 再设置回客户端。

const setCookie = require('set-cookie-parser');

function setCookies(cookis) {
    const parsedCookies = setCookie.parse(cookis || []) || [];
    if (ctx.headerSent) {
        return;
    }
    parsedCookies.map((cookieInfo) => {
        const { name, value, path, domain, expires, secure, httpOnly, sameSite } = cookieInfo;
        try {
            ctx.cookies.set(name, value, {
                overwrite: true,
                path,
                domain,
                expires,
                secure,
                httpOnly,
                sameSite,
            });
        } catch (err) {
            logger.error(err);
        }
    });
}

overwrite 设置为 true 是因为当我们有多个 CGI 请求，所返回的同名 set-cookie如果不覆盖的话，会使得 SSR 返回的 HTTP 头很大。

还要说说 secure 参数。这个参数表示 cookie 是否只能是 HTTPS 下传输。我们的应用是在 tsw 服务之后的，一般来讲也都会在 nginx 之后以 http 提供服务。那么我们就设置不了这个 secure 参数。如果要设置的话，需要有两步：

1. 初始化 koa 的时候，设置 proxy；

   const app = new Koa({ proxy: true })
   

2. koa 前面的代理设置 X-Forwarded-Proto 头部，表明是工作在 HTTPS 模式下；

但是实际上在我的服务里没有收到这个头部，因此仍然会报错，由于我们没法去改 tsw，也很清楚地知道我们是工作在代理之后，有个解决方案：

this.app.use(async (ctx, next) => {
    ctx.cookies.secure = true;
    await next();
});

4.2 并发和上下文隔离

我们来考虑这样一种情况：

当有两个请求 A 和 B 一前一后到达 Server，在经过一大串的异步逻辑之后。到达后面的那个处理逻辑的时候，它怎么知道它在处理哪个请求？方法当然是有：

1. 把 koa 的 ctx 一层一层传递，只要有涉及到具体请求的函数，都传递一下 ctx（是不是疯狂？）；

2. 或者把 ctx 存在 state 里，需要 ctx 的话从 state 里取（先不说这违反了 state 里应该放纯数据的原则，如果是一些工具函数呢？比如 getCookie 这样的函数，让它的 cookie 从哪里取？想想是不是头大？）；

因此我们需要想个办法，将 A 和 B 的请求隔离开来。

4.2.1 cluster 和 worker

如果说要隔离请求，我们可以有 cluster 模块提供进程粒度的隔离，也可以通过 worker_threads 模块提供线程粒度的隔离。但是难道我们一个进程和一个线程同时只能处理一个请求，只有一个请求完全返回结果后才能处理下一个吗？这显然是不可能的。

但是为了下面的错误捕获问题，我确实用 worker_threads + vm 尝试了好几种方法，虽然最后都放弃了。并且因为使用 worker_threads 可以共享线程数据的优点在这个场景下并没有多大的应用场景，反而是 cluster 可以共享 TCP 端口，最后是用 cluster + vm ，不过这是后话了。

4.2.2 domain

上下文隔离的技术，从 QQ 空间团队 tsw 那里学了个比较骚的方法，主要有两个关键点：

1. process.domain 总是指向当前异步流程的上下文，因此可以将需要的数据挂载到 process.domian 上；

2. 用 Object.defineProperty 设置数据的 getter 和 setter 函数，保证操作到的是 process.domain 上的对应数据；

用简短的代码演示就是这样的：

const domain = require('domain');

Object.defineProperty(global, 'myVar', {
    get: () => process.domain.myVar,
    set: (value) => {
        process.domain.myVar = value;
    },
});

const handler = (label) => {
    setTimeout(() => {
        console.log(`${label}: ${global.myVar}`);
    }, (1 + Math.random() * 4) * 1000);
};

for (let i = 0; i < 3; i++) {
    const d = domain.create();
    d.run(() => {
        global.myVar = i;
        handler(`test-${i}`);
    });
}

// test-1: 1
// test-0: 0
// test-2: 2

但是这个方案存在什么样的问题？

1. domain 没法保证虽然对象在它 run 函数里初始化，process.domain 一定有值，也可能是 undefined；

2. requre 过的文件，被 cache 了，需要执行清除缓存的操作，重新 require。虽然可以用 defineProperty 来定义值，但是如果有的模块是 const moduleVar = global.myVar; module.exports = moduleVar; 没有重新执行的话，导出的值将是错误的；

4.3 vm

上下文隔离，我们还可以用 vm 来做。（然后我们的挑战就变成了怎么把十几万行的代码放在 vm 里跑，为什么需要把十几万行代码都放进去？因为后面会说到被 require 的模块里访问 global 的问题，虽然后面的后面解决了这个问题）

vm 的一个基本使用姿势是这样的：

const vm = require('vm');

const code = 'console.log(myVar)';

vm.runInNewContext(code, {
    myVar: 'AlloyTeam',
    console,
});

// AlloyTeam

功能是不是很像 eval?，使用 eval 的话：

let num = 1;
eval('num ++');
console.log(num);

// 2

使用 Function 的话：

/**
 * @file function.js
 */
global.num = 1;
(new Function('step', 'num += step'))(1);
console.log(num);

// node function.js
// >2

细心的读者可能会发现，Function 的例子里，我写的是 global.num = 1 而不是 let num = 1，这是为什么？

1. 由 Function 构造器创建的函数不会创建当前环境的闭包，而是被创建在全局环境里；

2. 我这里的代码写在 function.js 文件里，是当做一个模块被运行的，是在模块的作用域里；

3. 基于以上 2 点，Function 里的代码能访问到的变量就是 global 和它的局部变量 step ，如果写成 let num = 1 将会报错；

使用 evel 和 Function 可以做到吗？感觉理论上像是可以的，假设我们给每个请求分配 ID，使用 Object.defineProperty 来定义数据的存取。但是我没有试过，而是使用成熟的 vm 模块，好奇的读者可以试一下。

另外因为我们并没有运行外部的代码，要在 vm 里跑的都是业务代码，因此不关心 vm 的进程逃逸问题，如果有这方面担忧的可以用 vm2。

4.3.1 global

我们在 Node 环境下访问全局变量，有两种方式：

(() => {
    a = 1;
    global.b = 2;
})();

console.log(a);
console.log(b);

// 1
// 2

而在 vm 里，是没有 global 的，考察以下代码：

const vm = require('vm');

global.a = 1;

const code = `
    console.log(typeof global);
    console.log(typeof a);
`;

vm.runInNewContext(code, {
    console,
});

// undefined
// undefined

因此假设我们要支持代码里能够以 global.myVar 和 myVar 两种方式来访问上下文里的全局变量的话，就要构造出一个 global 变量。

上下文的全局变量默认是空的，不仅 global 没有，还有一些函数也没有，我们来看看最终构造出的上下文是都有什么：

async getVMContext(renderJSFile) {
    const pathInfo = path.parse(renderJSFile);

    // 模块系统的变量
    const moduleGlobal = {
        __filename: renderJSFile,
        __dirname: pathInfo.dir,
    };

    const commonContext = {
        Buffer,
        process,
        console,
        require,
        exports,
        module,
    };

    /* 业务上定义的的全局对象，运行的时候会重新赋值
    * {
    *     window: undefined,
    *     navigator: {
    *         userAgent: '',
    *     },
    *     location: {
    *         search: '',
    *     },
    * }
    */
    const browserGlobal = renderConfig.vmGlobal(renderJSFile);

    return vm.createContext({
        ...commonContext,
        ...moduleGlobal,
        ...global,
        ...browserGlobal,
        // 重写 global 循环变量
        global: {
            ...browserGlobal,
        },
    });
}

4.3.2 require

前面说到 vm 的上下文默认是空的，然后我们给它传递了 module，exports，require，那么它能 require 外部模块了，但是被 require 的模块如果访问 global，会是 vm 里我们创建的 global，还是宿主环境下的 global 呢？

我们有个文件 vm-global-required.js 是要被 require 的：

const myVar = global.myVar;

console.log('[required-file]:', myVar);

我们还有个文件是宿主环境：

const vm = require('vm');

global.myVar = 1;

const code = `
    console.log("[vm-host]:", global.myVar);
    require('./vm-global-required');
`;

vm.runInNewContext(code, {
    global: {
        myVar: 2,
    },
    console,
    require,
});

运行代码，结果是：

// [vm-host]: 2
// [required-file]: 1

可以看到被 require 的模块所访问的 global 并不是 vm 定义的上下文，而是宿主环境的 global。

4.3.3 代码编译缓存

以 vm 创建的代码沙箱是需要编译的，我们不可能每个请求过来都重复编译，因此可以在启动的时候就提前编译缓存：

compilerVMByFile(renderJSFile) {
    const scriptContent = fileManage.getJSContent(renderJSFile);

    if (!scriptContent) {
        return;
    }

    const scriptInstance = new vm.Script(scriptContent, {
        filename: renderJSFile,
    });

    return scriptInstance;
}

getVMInstance(renderJSFile) {
    if (!this.vmInstanceCache[renderJSFile]) {
        const vmInstance = this.compilerVMByFile(renderJSFile);

        this.vmInstanceCache[renderJSFile] = vmInstance;
    }

    return this.vmInstanceCache[renderJSFile];
}

但是其实 v8 编译是不编译函数体的，好在可以设置一下：

const v8 = require('v8');
v8.setFlagsFromString('--no-lazy');

（编译部分还尝试过 createCachedData，可以详见以下错误捕获的使用 filename 章节）

4.3.4 超时

vm 运行的时候可以设置 timeout 参数控制超时，当超过时间后会报错：

const vm = require('vm');

const vmFunc = new vm.Script(`
    while(1) {}
`);

try {
    vmFunc.runInNewContext({
        http,
        console,
    }, {
        timeout: 100,
    })
} catch (err) {
    console.log('vm-timeout');
}

// vm-timeout

但是它的超时真的有效吗？我们来做个试验。如以下代码：

1. 设置了 timeout 是 100；

2. 用 process 监听了错误，如果超时触发了错误，process 就会捕获到错误输出出来；

3. /timeout-get 在 2000ms 后才返回结果；

const Koa = require('koa');
const Router = require('koa-router');
const vm = require('vm');
const http = require('http');

const app = new Koa();

const router = new Router();

router.get('/timeout-get', async (ctx) => {
    await new Promise((resolve) => {
        setTimeout(() => {
            ctx.body = 'OK';
            resolve();
        }, 2000);
    });
});

app.use(router.routes()).use(router.allowedMethods());

app.listen(3000);

process.on('unhandledRejection', (err) => {
    console.log('unhandledRejection', err);
});

process.on('uncaughtException', (err) => {
    console.log('uncaughtException', err);
});

console.time('http-cost');

const vmFunc = new vm.Script(`
    http.get('http://127.0.0.1:3000/timeout-get', (res) => {
        const { statusCode } = res;

        console.log('statusCode:', statusCode);
        console.timeEnd('http-cost');
        process.exit(0);
    })`
);

vmFunc.runInNewContext({
    http,
    console,
    process,
}, {
    timeout: 100,
    microtaskMode: 'afterEvaluate',
})

console.log('vm-executed');

输出结果是什么呢？

vm-executed
statusCode: 200
http-cost: 2016.098ms

说明 vm 的这个 timeout 参数在我们的场景下是不一定有效的，因此我们还需要在宿主环境额外设置超时返回。

4.4 错误捕获

我们的 SSR 和普通的后台服务最大的区别在于什么？我想是在于我们不允许返回空内容。后台的 CGI 服务在错误的时候，返回个错误码，有前端来以更友好的方式展示错误信息。但是 SSR 的服务，即使错误了，也需要返回内容给用户，否则就是白屏。因此错误的捕获显得尤为重要。

总结一下背景的话：

1. vm 所执行的代码可能来自于第三方，但是整个项目是提供基础镜像，第三方基于镜像自行部署的，因此不关心 vm 里的代码安全问题，不用用到 vm2

2. vm 里的代码是有可能出错的，错误可能来自于同步代码、异步代码或者未处理的 Promise 错误

3. vm 代码是异步并行的，假设每次执行 vm 代码都有一个 id

4. vm 里的代码即使出错，也必须要知道是哪个 id 的 vm 代码执行出错了，来执行兜底的策略

4.4.1 process 捕获

在 node 里，如果要捕获未知的错误，我们当然可以用 process 来捕获

process.on('unhandledRejection', (err) => {
    // do something
});

process.on('uncaughtException', (err) => {
    // do something
});

这代码不仅可以捕获同步、异步错误，也能捕获 Promise 错误。但同时，我们从 err 对象上也获取不了出错时候的上下文信息。像背景里的要求，就不知道是哪个 id 的 vm 出错了

4.4.2 try...catch

如果以 vm 来执行代码的话，我们大可以在代码的外部包裹 try...catch 来捕获异常。看下面的例子，try...catch 捕获到了错误，错误就没再冒泡到 process。

const vm = require('vm');

process.on('uncaughtException', (err) => {
    console.log('[uncaughtException]:', err);
});

const script = new vm.Script(`
    try {
        throw new Error('from vm')
    } catch (err) {
        console.log(err)
    }
`);

script.runInNewContext({ Error, console });

// Error: from vm
//     at evalmachine.:3:15

4.4.3 异步错误

改写上面的例子，将错误在异步函数里抛出，try...catch 捕获不到错误，错误冒泡到 process，被 uncaughtException 事件捕获到

const vm = require('vm');

process.on('uncaughtException', (err) => {
    console.log('[uncaughtException]:', err);
});

process.on('unhandledRejection', (err) => {
    console.log('[unhandledRejection]:', err);
});

const script = new vm.Script(`
    try {
        setTimeout(() => {
            throw new Error('from vm')
        })
    } catch (err) {
        console.log(err)
    }
`);

script.runInNewContext({ Error, console, setTimeout });

// [uncaughtException]: Error: from vm
//     at Timeout._onTimeout (evalmachine.:4:19)

那有什么办法捕获异步错误吗？办法还是有的，node 里有个 domain 模块，可以用来捕获异步错误。（虽然已经标记为废弃状态，但是已经用 async_hooks 重写了，意味着即使真的被废弃，也能自己实现一个）

继续改写上面的例子，将 vm 放在 domain 里执行，可以看到错误被 domain 捕获到了

const vm = require('vm');
const domain = require('domain');

process.on('uncaughtException', (err) => {
    console.log('[uncaughtException]:', err);
});

process.on('unhandledRejection', (err) => {
    console.log('[unhandledRejection]:', err);
});

const script = new vm.Script(`
    try {
        setTimeout(() => {
            throw new Error('from vm')
        })
    } catch (err) {
        console.log(err)
    }
`);

const d = domain.create();

d.on('error', (err) => {
    console.log('[domain-error]:', err);
});

d.run(() => {
    script.runInNewContext({ Error, console, setTimeout });
});

// [domain-error]: Error: from vm
//     at Timeout._onTimeout (evalmachine.:4:19)

4.4.4 Promise 错误

但是假如将上一个例子的 vm 代码改成 Promise 执行呢？domain 捕获不到错误，错误冒泡到 process 上

const vm = require('vm');
const domain = require('domain');

process.on('uncaughtException', (err) => {
    console.log('[uncaughtException]:', err);
});

process.on('unhandledRejection', (err) => {
    console.log('[unhandledRejection]:', err);
});

const script = new vm.Script(`
    Promise.resolve().then(() => {
        throw new Error('notExistPromiseFunc')
    })
`);

const d = domain.create();

d.on('error', (err) => {
    console.log('[domain-error]:', err);
});

d.run(() => {
    script.runInNewContext({ Error, console, setTimeout });
});

// [unhandledRejection]: Error: notExistPromiseFunc
//     at evalmachine.:3:15

为什么？node 文档里是这么说的

Domains will not interfere with the error handling mechanisms for promises. In other words, no 'error' event will be emitted for unhandled Promise rejections.

那有什么办法吗？这里想了两个比较骚的写法。

4.4.4.1 使用 filename

我们知道 vm 在执行的时候，是可以提供一个 filename 属性，在错误的时候，会被添加到错误堆栈内。默认值是 'evalmachine.' 也就是我们上面的错误经常看到的第二行代码错误的位置。这就带来了操作的空间。

const vm = require('vm');
const markStart = '';
const markEnd = '';

const getContext = () =>
    vm.createContext({
        console,
        process,
        setTimeout,
    });

const parseErrorStack = (err) => {
    const errorStr = err.stack;

    const valueStart = errorStr.indexOf(markStart);
    const valueEnd = errorStr.lastIndexOf(markEnd);

    if (valueStart !== -1 && valueEnd !== -1) {
        return errorStr.slice(valueStart + markStart.length, valueEnd);
    }

    console.log('[parse-error]');
    return null;
};

process.on('unhandledRejection', (err) => {
    console.log('[unhandledRejection]:', parseErrorStack(err));
});

process.on('uncaughtException', (err) => {
    console.log('[uncaughtException]:', parseErrorStack(err));
});

const getScript = (flag) => {
    const filename = `${markStart}${flag}${markEnd}`;

    return new vm.Script(
        `
        (() => {
            new Promise((resolve, reject) => {
                setTimeout(() => {
                    reject(new Error('${flag}'));
                }, 100)
            })
        })()
    `,
        { filename }
    );
};

(async () => {
    for (let i = 0; i < 3; i++) {
        await getScript(i).runInContext(getContext());
    }
})();

// [unhandledRejection]: 0
// [unhandledRejection]: 1
// [unhandledRejection]: 2

看下上面的代码结构，我们做了几件事：

1. 在 vm 代码编译的时候，以 vm-error 标识符标记了我们要传递到错误堆栈的值

2. 在 process 捕获 Promise 错误

3. 在 process 捕获到 Promise 错误的时候，从错误堆栈上根据标识符解析出我们要的值

但是这样的代码存在什么问题？

最主要的问题在于 filename 是编译进去的，即使生成 v8 代码缓存的 Buffer，后面用这个 Buffer 来编译一个新的 script 实例，传递进新的 filename，仍然改变不了之前的值。所以会带来代码每次都需要编译的成本。

我们可以来实践以下：

const vm = require('vm');
require('v8').setFlagsFromString('--no-lazy');

const markStart = '';
const markEnd = '';

const getContext = myVar => vm.createContext({
    console,
    process,
    setTimeout,
    myVar,
});

const parseErrorStack = (err) => {
    const errorStr = err.stack;

    const valueStart = errorStr.indexOf(markStart);
    const valueEnd = errorStr.lastIndexOf(markEnd);

    if (valueStart !== -1 && valueEnd !== -1) {
        return errorStr.slice(valueStart + markStart.length, valueEnd);
    }

    console.log('[parse-error]');
    return null;
};

process.on('unhandledRejection', (err) => {
    console.log('[unhandledRejection]:', parseErrorStack(err));
});

process.on('uncaughtException', (err) => {
    console.log('[uncaughtException]:', parseErrorStack(err));
});

const getFileName = flag => `${markStart}${flag}${markEnd}`;

const code = `
(() => {
    new Promise((resolve, reject) => {
        setTimeout(() => {
            reject(new Error(myVar));
        }, 100)
    })
})()
`;

const scriptCache = new vm.Script(code, {
    filename: getFileName(-1),
});

const scriptCachedData = scriptCache.createCachedData();

const getScript = flag => new vm.Script(' '.repeat(code.length), {
    filename: getFileName(flag),
    cachedData: scriptCachedData,
});

(async () => {
    for (let i = 0; i < 3; i++) {
        await getScript(i).runInContext(getContext(i));
    }
})();

看上面的代码，对比上一个例子，主要有这几个改动：

1. 缓存了 vm 代码编译后的实例，filename 设置的 -1

2. 循环内的 flag 标志是通过 myVar 注入到 vm 的全局变量，在 vm 里 throw 这个 flag 错误值的

3. 循环内的 vm 执行，filename 设置的 0 - 3

结果：编译后的代码实例并不会因为使用 cachedData 重新编译后，filename 就会被改变，因此就无法使用 cacheData + filename 的方式来既要减少编译时间又想要自定义错误堆栈。

4.4.4.2 重写 Promise

当我们想同步和异步代码都能捕获得到，那么只剩下 Promise 错误了。什么情况会报 Promise 未处理的错误呢？也就是没有写 catch 的情况。那么如果我们改写 Promise ，将每个 Promise 都加上一个默认的 catch 函数，是否能达到期望呢？

const vm = require('vm');

let processFlag;

process.on('unhandledRejection', (err) => {
    console.log('[unhandledRejection-processFlag]:', processFlag);
});

const getVMPromise = (flag) => {
    const vmPromise = function (...args) {
        const p = new Promise(...args);

        p.then(
            () => {},
            (err) => {
                processFlag = flag;
                throw err;
            }
        );

        return p;
    };
    ['then', 'catch', 'finally', 'all', 'race', 'allSettled', 'any', 'resolve', 'reject', 'try'].map((key) => {
        if (Promise[key]) {
            vmPromise[key] = Promise[key];
        }
    });

    return vmPromise;
};

const getContext = (flag) =>
    vm.createContext({
        Promise: getVMPromise(flag),
        console,
        setTimeout,
    });

const getScript = (flag) => {
    return new vm.Script(`
        new Promise((resolve, reject) => {
            setTimeout(() => {
                console.log("[vm-current-task]:", "${flag}");
                reject()
            }, (1 + Math.random() * 4) * 1000);
        })
    `);
};

for (let i = 0; i < 3; i++) {
    getScript(i).runInContext(getContext(i));
}

// [vm-current-task]: 0
// [unhandledRejection-processFlag]: 0
// [vm-current-task]: 2
// [unhandledRejection-processFlag]: 2
// [vm-current-task]: 1
// [unhandledRejection-processFlag]: 1

考察以上的代码，我们做了这些事：

1. 改写了 Promise，在 Promise 添加了第一个 then 方法来处理错误

2. 在自定义的 Promise 的第一个 then 方法里存储了当前异步任务的上下文

3. 将自定义的 Promise 当做全局变量传递给 vm

结果：在一个随机的任务 ID 上，成功在 process 上捕获到了上下文的信息。(但是 Promise 实现的精华在于 then 之后的链式调用，这在上面的代码是没有体现的。)

4.4.5 必要性思考

重写 Promise 的方案可行吗？看起来是可行的，但其实最后也没有用这个方案（其实是我还没实施。。。）。因为假设我一个 32 核的 Pod，fork 出 32 个进程处理请求，平均分到每个进程的请求同一时间也不会很多。而出错是应该在编码和系统测试就应该避免的，或者自动化测试，或者生成骨架屏时避免。如果要同时捕获这三个错误，需要在异步代码都使用 domain 捕获（可能会有性能问题）和 Promise 记录上下文。其实我们可以在出错的时候将当前进程所处理的所有请求直接返回原文档，回退到无 SSR 的状态。（不过 Promise 的方案仍然值得研究尝试一下，会发大篇幅也是因为之前陷进去了这个问题，研究了好一段时间）

4.5 重定向

登录态的问题和文档强相关，但是仍然想要抛出来和大家探讨一下重定向的这个问题。

腾讯文档的登录态在前端是无法完全判断的，只有两种最基本的情况前端是知道没有登录态：

1. 没有 cookie；

2. cookie 里没有 uid 和 uid_key；

如果是登录态过期，那么只能是在发起 CGI 请求，后台返回具体的错误码之后才知道。所以 CSR 的登录是在列表页显示，并且正常渲染的情况下，发现 CGI 有具体的登录态错误码了，就动态加载登录模块来提醒用户登录。整个的效果就是这样的：

4.5.1 rewrite

当我们引入了 SSR 后，发送 CGI 请求遇到特定的登录态错误码我们是知道的。那么我们为什么不直接返回登录页就可以了呢？很简单，直接 ctx.redirect 302 重定向到登录页就可以了，但是问题来了：

1. 我们的 PC 端没有独立的登录页，是用动态加载模块的方式来在当前页面展示登录框的；

2. 需要处理 URL 跳转的问题，不仅是从外部跳转过来的带有登录态的 URL，还要处理登陆完后的 URL 跳转问题；

3. 登录的模块在其他的库，就需要去改到那个库发布才可以；

有没有更好的方法呢？

1. 我们另外做一个很简单的 login 页面，这个页面只用来做一件事，复用原来的代码在这个页面动态加载登录模块；

2. 如果用户登录态有效，返回请求的页面，如果登录态失效，就读取 login 页面的内容返回；

这样就做到了不用更改登录模块逻辑，也不会更改到链接地址，也就不用处理 URL 跳转的问题。

但是需要注意的是，因为以下会提到同时接入 SSR 服务和原 Nginx 服务，因此如果要不改变现网表现的话，login 页面不应该被发到 Nginx 机器上。类似的还有独立密码的登录页。

这样实现的效果就是：

4.5.2 redirect

像上面的登录态问题，在移动端上有独立的登录页，那么我们就只需要用 ctx.redirect 使用 302 跳转到对应的页面就 OK 了。相似的应用场景还有如果是 PC 端访问了移动端的 URL 地址，或者移动端访问了 PC 端的地址，需要读取 UA 来判断访问端和 URL 地址，跳转到对应的页面。

4.5.3 小程序登录态

要额外提到的小程序登录态是因为，小程序是通过小程序壳登录，再将登录态附加在 webviewer 里的 URL 地址上，由前端解析 URL 地址来种登录态的。这意味着小程序登录后，SSR 的 cookie 里是没有登录态的，发起 CGI 请求就会报错。所以我们就需要做两件事：

1. 从 URL 上解析登录态，将登录态信息附加到当次请求的 cookie 里，保证当次请求不会出错，也不会因为没有登录态重复跳到登录页；

2. 设置新的具有登录态的 cookie 到客户端；

const appendAndSetCookie = (ctx, key, value) => {
    const oldCookie = ctx.header.cookie || '';
    ctx.header.cookie = `${oldCookie}${oldCookie.endsWith(';') ? '' : ';'}${key}=${value};`;

    ctx.cookies.set(key, value);
};

5. 骨架屏

5.1 基本实现

回顾整个生成首屏页面的流程：

1. 创建 redux 的 store；

2. 发送 CGI 填充 store 数据；

3. 以 store 的数据为基础渲染 react 应用；

除了发送 CGI 这一步需要在线上环境，在用户浏览器发起请求时由 SSR Server 代理请求外，空的 store 和以空的 store 渲染出 React 应用，是我们在编译期间就可以确定的。那么我们就可以很方便地获得一个骨架屏，而所需要做的在原来 SSR 的基础上只有几步：

1. 创建一个空的 ctx，以复用原来的 SSR 逻辑：

   const generateCTX = (renderJSFile, renderHtmlFile) => ({
       headers: [],
       url: '',
       body: '',
       renderJSFile,
       renderHtmlFile,
       originalUrl: '',
       request: {
           href: '',
       },
   });
   

2. 传递给应用标识当前是生成骨架屏逻辑，应用里不发送 CGI：

   if (!TSRENV.isSkeleton) {
       await Promise.all([
           store.dispatch.user.requestGetUserInfo(),
           store.dispatch.list.refreshRecentOpenList(),
       ]);
   }
   

3. 将生成的 HTML 写入原文档：

   if (renderConfig.skeleton.writeToFile) {
       fileManage.writeHtmlFile(renderHtmlFile);
   }
   

   但是这里我们考虑应该以怎样的方式来写入。假设原来是将

   里的 server-render 整个标签（包括 div）替换成渲染后的文档（为什么原来不也是用注释的方式？因为很可能编译后会被去掉注释）。那么我们生成的骨架屏也将这个替换掉的话，后续 SSR 找不到这个标签。如果插入在这个标签里面的话，显然骨架屏生成的 DOM 在层级上和 SSR 生成的 DOM 是不一样的。这里我们可以借助注释。

   原来的文档：

骨架屏文档（编译完 CSR 后再生成）：

SSR 后文档: