SSG（Nuxt/Next）内容更新机制解析及与CSR的差异探讨

1. “内容更新必须重新构建”具体指什么？ #

这里的**“内容”特指SSG在构建阶段预渲染到静态HTML里的内容**——比如页面的基础骨架、固定静态文本、构建时通过服务端/本地数据源获取并注入的结构化数据（比如Next.js的getStaticProps、Nuxt的asyncData在静态生成模式下返回的数据）。

这些内容会被直接打包成静态HTML文件，部署到服务器或CDN后，用户请求时直接返回这个预先生成的文件。如果要修改这部分内容，必须重新执行构建命令（如next build/nuxt generate），重新生成对应的静态HTML，再重新部署才能生效。

而你在created/mounted等客户端钩子中调用API更新的内容，属于客户端动态渲染的部分——这部分是浏览器加载JS后才请求数据并更新DOM的，不属于SSG预构建的范畴，自然不需要重新构建。

2. 是否可以理解为SSG先返回预构建的文档，再通过Hydration实现类SPA的运行模式？ #

完全正确，这就是现代SSG（Next.js/Nuxt）的标准工作流：

• 构建阶段：生成包含完整预渲染内容的静态HTML文件，同时打包对应的JS组件逻辑。
• 请求阶段：用户访问页面时，服务器/CDN直接返回预构建的HTML，用户能快速看到页面内容（解决CSR首屏白屏问题）。
• 水合阶段：浏览器加载对应的JS bundle后，执行Hydration操作——把静态HTML节点“激活”成可交互的Vue/React组件，之后页面就具备了SPA的特性：客户端路由、动态数据请求、组件状态管理等，进入类SPA的运行模式。

3. SSG（Nuxt/Next）的内容更新机制与CSR有何不同？ #

两者的核心差异在于内容生成的时机和依赖的环境：

触发与执行环境 #

• SSG：静态内容的更新依赖构建阶段的服务端/本地环境，必须重新构建、重新部署才能生效；客户端动态内容的更新和CSR类似，但基础内容是预渲染好的。
• CSR：所有内容的更新都在客户端浏览器环境触发，只需通过API拉取新数据，无需构建或部署。

内容来源与更新成本 #

• SSG：静态内容来自构建时的数据源（本地MD文件、构建时调用的接口），更新成本高（需重新打包部署），适合更新频率低的内容（如官网文档、博客文章）；客户端动态内容则和CSR一致，实时性高。
• CSR：所有内容都来自客户端运行时的API请求，更新成本低，实时性强，适合更新频繁的内容（如后台管理系统、社交动态）。

用户体验与缓存 #

• SSG：首屏加载速度快，用户能快速看到内容；静态HTML文件可在CDN做长期缓存，缓存效率极高。
• CSR：首屏需等待JS加载解析完成后才渲染内容，可能出现白屏；JS bundle可缓存，但内容是动态拉取的，缓存策略更复杂。

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