请问框架内部如果不使用 runInNewContext，是如何处理单例或其他一些副作用逻辑的？🕵️‍♀️

[Liubasara]

在对一个 Vue 的巨石单页应用进行改造的时候遇到了这个问题，项目中大量使用了单例，如果全部将其挂载到应用级 app 上影响面过大，无法接受。所以只能使用 vm 模块的 runInNewContext。偶然间看到了文档中的这段话：

高性能
没有 runInNewContext，我们不像其他框架的做法一样使用 vm 模块创建上下文来解析服务端 bundle，所以我们的性能是极高的。等于直接调用框架提供的原生 API 无任何中间层损耗

不基于 createBundleRenderer
目前业界几乎所有与 VueSSR 有关的框架底层本质都是使用了官方的vue-server-renderer 提供的 createBundleRenderer 来进行核心渲染逻辑。这会有很多问题

createBundleRenderer 内部的逻辑对使用者和框架开发者来说完全是黑盒
createBundleRenderer 强耦合 vm 模块。无论怎么配置 runInNewContext 选项都会使用 vm 模块来解析 js
createBundleRenderer 内部的异步依赖收集逻辑过于复杂。且与 vue-loader 强耦合。并且 Vue3 版本官方的 createBundleRenderer 尚未出现。也就是在 Vue3/React 场景这块方案是用不了的
强耦合 vue-server-renderer/client-plugin, 异步依赖收集前必须首先使用该 Webpack 插件构建出模块信息资源清单
事实上在 ssr 框架内部我们实现了一个非常轻量级可以在所有前端框架场景适用的异步模块收集过程和渲染器。

请问框架内是如何处理的呢？有大神知道吗。

[zhangyuang]

你这个问题本质就是不同的请求访问了同一个对象互相污染的问题，这个你应该从应用层面来解决而不是框架来帮你解决。如果不想挂载到app实例上可以用async_localstorage

[Liubasara]

感谢您的及时回复，我去看看。