1.渲染方式和SPACSR客户端渲染Client-Side Rendering用户访问网页时服务器只返回一个基础的 HTML 空壳文件。浏览器下载并执行JS后由JS动态获取数据并生成DOM结构最终渲染出页面前后端分离彻底服务器压力小,交互流畅首屏白屏时间长SEO极差vue、react默认都是CSR渲染SSR服务端渲染Server-Side Rendering用户发起请求时服务器端提前执行前端框架逻辑生成包含完整内容的 HTML页面并直接返回给浏览器。浏览器收到后即可直接渲染无需等待 JS 执行。首屏加载极快SEO 友好但服务器需要承担渲染压力传统SSR服务器必须等所有数据获取完毕、整个页面的 HTML 全部生成后才一次性发送给浏览器。如果某个接口特别慢整个页面都会卡住白屏流式渲染SSR:打破了这种全有或全无的模式。利用 HTTP1.1 的分块传输编码机制允许服务端在生成部分HTML后就将其作为数据块Chunk实时推送给客户端。浏览器接收到一个块就立刻开始解析和渲染无需等待全部内容就绪。大幅降低TTFB首字节时间用户能尽早看到页面的基础框架或骨架消除白屏焦虑服务端不需要缓存完整的HTML字符串生成一块发送一块降低内存峰值SSG静态站点生成Static Site Generation在项目的构建阶段就提前生成好所有页面的 HTML 文件。用户访问时服务器直接返回这些预生成的静态文件无需进行动态计算。加载极快安全性高服务器压力极低但内容更新困难每次修改都需要重新构建整个站点ISR增量静态再生Incremental Static Regeneration结合了SSG和动态更新的优点。页面首次访问时是静态生成的当内容发生变化时系统会在后台自动触发页面的重新生成并更新缓存。兼顾了静态页面的高性能与动态内容的灵活性适合电商商品页、内容聚合页等场景SPA单页面应用Single Page Application整个应用的生命周期中只加载一次 HTML 页面。后续的页面切换、数据更新全部通过JS动态加载和局部更新来实现不会触发整个页面的刷新页面切换无需重新加载响应速度极快体验接近原生桌面/移动应用。前后端分离前端负责 UI 呈现和交互后端只负责提供数据减轻服务器负担服务器只需提供 SON数据不再负责 HTML 模板渲染首次加载较慢初次访问需要下载大量的JS和CSS 代码在弱网环境下白屏时间长SEO 不友好页面内容由JS动态生成传统的搜索引擎爬虫难以抓取和索引完整内容内存占用较高复杂应用在客户端运行大量JS容易导致内存消耗过大MPA多页面应用Multi-Page Application由多个独立的 HTML 页面组成。每次用户在页面间跳转时浏览器都会向服务器发起请求重新加载整个页面及相关的资源。SEO 极其友好每个页面都是独立的 HTML易于被搜索引擎抓取开发模式简单直观初始加载速度快。用户体验较差每次切换页面都需要重新请求和渲染有明显的卡顿感和白屏时间代码复用率低维护成本较高。Serverless无服务器架构开发者无需关注底层服务器资源的配置、维护和扩展。云服务商将底层基础设施完全抽象化开发者只需上传业务代码由云平台自动运行和管理。事件驱动代码以函数为单位由HTTP请求、数据库变更、定时任务等事件触发执行极致的弹性伸缩根据实际请求量动态分配计算资源。零流量时成本趋近于零高并发时能瞬间扩容至数万实例按使用量计费摒弃了传统服务器“按实例时长计费”的模式仅对代码实际执行的时长和调用次数精确计费冷启动延迟函数长时间未被调用后首次触发时需要经历环境初始化和依赖加载过程可能产生数百毫秒到数秒的延迟。供应商锁定风险不同云平台的 Serverless 服务在函数运行时、事件源集成上存在差异跨平台迁移成本较高1.对比 SPA 和 MPA 的优缺点在实际项目中如何选择SPA 体验好但 SEO 差MPA SEO 好但体验差。在实际工程中通常采用混合架构例如面向 C 端的官网首页、博客采用 MPA或 SSR以保障 SEO而面向内部员工的后台管理系统、SaaS 工具采用 SPA以保障复杂的交互体验。2.SPA的SEO不友好问题怎么解决传统的纯CSR确实不利于 SEO但现在可以通过引入SSR或SSG来解决。如使用Next.js / Nuxt.js 框架或者在构建时使用预渲染Prerender技术提前将关键页面的内容生成为静态 HTML 供搜索引擎抓取。3.Serverless和传统的SSR结合有什么优势传统的 SSR 需要企业自己维护 Node.js 服务器在流量低谷时会造成资源浪费在流量洪峰时又容易宕机。将 SSR 部署在 Serverless 架构上可以利用 Serverless 的自动弹性伸缩能力应对电商秒杀等突发流量同时大幅降低闲置时的服务器成本4.SSR 和 SSG 应该怎么选看内容的更新频率。如果页面内容是高度动态的如新闻列表、电商商品详情、用户个人中心选SSR如果页面内容相对固定、极少变动如个人博客、产品文档、公司官网介绍选择 SSG以获得极致的加载性能和最低的运维成本5.如何前端架构选型在我的 Vue2项目中主要使用的是基于Webpack的CSR 架构因为中后台系统不需要 SEO。面向C端的项目为了解决CSR首屏慢和SEO差的问题我们引入了Nuxt.js 进行 SSR改造。针对部分更新频率极低的页面可开启SSG 模式6.SSR虽然首屏快但有什么致命缺点怎么优化SSR 的致命缺点是服务器 CPU 压力大且如果某个接口慢会导致整个页面阻塞。为此我们做了两点优化一是引入流式渲染Streaming SSR让页面框架先展示慢数据后加载二是结合Serverless架构进行部署利用其弹性伸缩能力应对流量洪峰降低闲置成本7.Vue2 的 Webpack 打包体积过大首屏加载慢怎么排查和优化使用webpack-bundle-analyzer分析包体积。优化方式有路由懒加载、UI 库按需引入开启生产环境的 Tree-shaking 和 Gzip 压缩将 Vue 等基础库通过 CDN 引入并在 Webpack 中配置 externals 排除打包8.Nuxt.js和Serverless的关系使用Nuxt.js 结合 Serverless 架构。Nuxt.js 负责提供开箱即用的SSR能力和 BFF 接口聚合而 Serverless 架构则接管了底层的服务器运维。这种组合不仅利用 Serverless 的弹性伸缩完美应对了业务的流量波峰波谷降低了服务器成本还通过 Nuxt 的混合渲染SSG SSR策略实现首屏秒开和极致的SEO表现9.如何把一个CSR项目重构为SSR项目使用Nuxt.js框架由框架接管流式渲染的底层逻辑将Vue 页面组件迁移至 Nuxt 的pages/目录通用组件放入components/业务逻辑抽离为composables/。改造数据获取方式将原来在onMounted中发起的客户端 API 请求改为使用 Nuxt 提供的useFetch或useAsyncData。这能确保数据在服务端提前预取并无缝注入到流式渲染的 HTML 中。/ CSR 写法 onMounted(async () { const data await fetch(/api/article).then(r r.json()); });// SSR 写法 const { data } await useFetch(/api/article);利用框架内置的流式渲染能力Nuxt.js3底层天然支持流式 SSR。对于包含复杂耗时数据的页面直接使用 Vue3 的Suspense组件将页面拆分为独立区块。Nuxt 会自动处理流式推送让页面框架秒出慢数据区块在就绪后渐进式填充从而将首字节时间TTFB压缩到 200ms 以内。动态管理SEO标签使用 Nuxt 提供的useHead组合式函数动态管理每个页面的title和meta标签框架会自动在流式渲染的head中正确注入这些内容。React 系React 18 Next.js 13 (App Router)Vue 系Vue 3 Nuxt 3运行时Node.js 182.Nuxt.jsNuxt.js基于 Vue构建的开源全栈Web应用框架。目标让开发者能够以直观、高性能的方式快速创建生产级、类型安全的 Web 应用和网站。是将 Vue升级为现代化、高性能、全栈化开发体验的终极解决方案npx nuxilatest init my-ssr-app极致的自动化与约定优于配置通过预设的目录结构自动处理了大量重复性工作基于文件的路由你只需在pages/目录下创建.vue文件Nuxt 就会根据文件夹结构自动生成路由配置无需手动编写路由表。自动导入在指定的目录如components/或composables/中编写的组件和组合式函数可以在项目中直接使用无需手动import。这得益于其内置的 Tree-shaking 机制保证了代码的按需加载。零配置 TypeScript借助自动生成的类型声明和tsconfig.json开发者无需深入配置即可享受完整的类型安全提示。开箱即用的构建工具默认使用 Vite 作为打包工具提供开发环境下的热模块替换HMR以及生产环境的最佳实践打包。SSR服务端渲染与多模式支持Nuxt默认内置了服务端渲染能力无需自行搭建Node服务器性能与SEO服务端直接返回完整渲染的HTML大幅提升首页加载速度改善了弱网和低性能设备上的体验同时让搜索引擎能更好地抓取内容灵活的渲染模式除了默认的 SSRNuxt 还支持静态站点生成SSG、纯客户端渲染SPA甚至可以通过routeRules实现精确到页面级别的混合渲染策略。内置全栈能力Nitro服务器引擎Nuxt不仅是前端框架还内置了Nitro轻量级服务端引擎API 自动生成只需在server/api/目录下编写文件Nuxt 就会自动将其暴露为服务端 API 接口。服务端中间件支持在server/middleware/中编写服务端逻辑用于鉴权、日志记录无缝数据获取提供了useFetch、useAsyncData等内置组合式函数完美兼容 SSR 环境下的数据请求避免了传统 CSR 中繁琐的“先加载骨架屏再请求数据”的流程。无供应商锁定的灵活部署Nuxt.js 没有绑定任何特定的云服务商。得益于 Nitro 引擎在生产构建时它会将应用和服务器打包成一个极其轻量的通用输出.output目录。这使得你可以将 Nuxt 应用一键部署到任何支持 JavaScript 的环境中包括传统的 Node.js/Deno 服务器、Serverless 架构、边缘计算节点Edge甚至是纯静态的托管平台3.Next.jsNext.js最主流的React全栈框架。Next.js是由Vercel公司开发的开源React 框架为构建生产级、支持SSR服务端渲的全栈 Web 应用而设计。在React基础上扩展了路由、多种渲染策略、后端能力和性能优化让开发者可以在单一代码库中处理前后端逻辑。支持SSR服务端渲染、SSG静态站点生成、CSR客户端渲染以及ISR增量静态再生文件系统路由通过文件夹和文件的结构直接映射为URL路由无需手动配置路由表。内置 API 路由允许在同一个项目中编写后端接口Serverless Functions替代传统的独立后端服务。极致的性能优化内置自动代码分割、图片优化和字体优化显著提升首屏加载速度LCP创建项目npx create-next-applatest启动开发服务器npm run dev默认访问http://localhost:3000构建生产包npm run build启动生产服务器npm start两大路由系统Next.js 目前并存两套路由系统新项目推荐使用 App RouterApp Router现代推荐使用app目录。支持 React Server Components (RSC)、嵌套布局Layouts、流式渲染Streaming等现代特性。组件默认在服务端运行若需交互需在文件顶部声明use client。Pages Router遗留使用pages目录。基于文件名的经典路由系统不支持流式渲染目前仍被完全支持但新特性将不再向此系统更新。核心API与数据获取服务端数据获取在 App Router 中直接在 Server Components 中使用原生async/await fetch即可在服务端获取数据。在 Pages Router 中使用getServerSideProps每次请求获取或getStaticProps构建时获取。API 路由后端接口在pages/api目录下创建文件如users.js会自动暴露为/api/users接口。开发者可直接在此处理请求、连接数据库等。中间件Middleware支持在请求到达页面之前执行代码常用于 JWT 身份验证、请求限流、重定向等横切关注点。内置组件Image /自动处理图片懒加载、尺寸响应和格式转换如 WebP/AVIF。Link /实现客户端路由切换自动预取目标页面资源。1.Next.js 和普通的 React有什么区别普通 React 默认是 CSR客户端渲染存在首屏白屏时间长和 SEO 不友好的问题。Next.js 作为框架提供了开箱即用的 SSR/SSG 能力解决了首屏性能和 SEO 痛点。同时Next.js 内置了文件系统路由、自动代码分割和 API 路由简化了工程化配置是一个全栈解决方案2.解释 Next.js中的SSR、SSG 和 ISR以及它们的应用场景SSR服务端渲染每次请求都在服务端生成 HTML。适合数据实时变化、高度个性化的页面如用户后台、搜索结果页。SSG静态站点生成在构建时生成 HTML后续请求直接从 CDN 读取。适合内容极少变动的页面如博客、文档、营销页性能最好。ISR增量静态再生结合了 SSG 和 SSR 的优点。允许在部署后按设定的时间间隔如 60 秒在后台重新生成特定页面的静态 HTML兼顾了高性能与数据新鲜度如电商商品列表。3.什么是 React Server Components (RSC)在 Next.js 中如何使用RSC 允许组件仅在服务端渲染其代码永远不会打包发送到浏览器从而大幅减小 JS 体积。在 Next.js 的 App Router 中所有组件默认都是 Server Components。如果组件需要绑定事件、使用 Hooks如useState或访问浏览器 API必须在文件顶部添加use client指令将其声明为客户端组件。4.Next.js如何优化首屏性能Next.js 提供了多维度的性能优化。首先是自动代码分割每个页面只加载所需的 JS其次是预渲染SSR/SSG减少客户端渲染耗时第三是内置优化组件如Image /自动实现懒加载和响应式尺寸Font /避免布局偏移CLS最后是支持流式渲染Streaming SSR配合Suspense让页面骨架先返回慢数据区块后加载极大缩短 TTFB。5.Next.js 的 API 路由和传统的后端服务有什么区别Next.js 的 API 路由本质上是 Serverless Functions。它允许开发者在同一个代码库中编写 BFFBackend for Frontend层直接与前端状态打通避免了跨域问题。但对于极其复杂的微服务架构、长连接或高并发计算依然建议使用 NestJS 等专业后端框架Next.js 仅作为网关或轻量级聚合层。