Next.js使用React Context API是否禁用SSG？客户端请求自定义Node服务是否影响静态生成？

问题1：使用React Context API是否会导致SSG被禁用？ #

首先先纠正一个常见误区：正常使用Redux也不会禁用SSG，你之前了解到的所谓Redux禁用SSG的情况，大概率是开发者错误地在getStaticProps/getStaticPaths这类Node环境运行的SSG数据获取函数中调用了客户端Redux的相关逻辑导致的报错，和Redux本身无关。

回到React Context的问题：完全不会禁用SSG。
Context本身是客户端React树的状态管理机制，而SSG的核心逻辑是在构建阶段（Node环境）预生成静态页面的HTML、资源文件，二者的运行时机完全隔离。你只要不在SSG专属的服务端运行逻辑里调用Context相关API（本来也调用不了，这些逻辑运行时还没有客户端React实例），完全可以正常在_app.js/根组件里包裹Context Provider做全局状态管理，SSG的构建流程不会受到任何影响，等用户访问页面、客户端完成hydrate之后，Context会正常接管全局状态的工作。

问题2：客户端侧从自定义Node服务拉取数据是否会禁用SSG，是否有性能负面影响？ #

对SSG的影响 #

完全不会禁用SSG。
SSG的静态资源是构建阶段就生成好的，客户端发起请求拉取数据是用户访问到静态页面之后，在浏览器侧运行JS触发的操作，和SSG的构建、运行逻辑完全不冲突，不会对SSG的正常使用造成任何干扰。

对性能的影响 #

要看你拉取的数据类型：

• 如果是首屏必须展示的核心公共内容：这种情况客户端拉取会导致用户打开页面后先看到无核心内容的空白/骨架屏，等请求返回才能渲染对应内容，首屏加载体验比你在SSG构建阶段直接拉取数据嵌入静态页要差，确实有性能负面影响。
• 如果是用户个性化内容、交互后才展示的非首屏内容：这种场景下客户端拉取是标准实现方案，不会对性能产生负面影响，反而可以减少SSG构建的复杂度，也能保证静态页的缓存效率。

另外要注意如果你的自定义Node服务和Next.js静态资源部署域名不同，要提前配置好CORS规则，避免跨域请求被拦截。

内容的提问来源于stack exchange，提问作者Bob Stone