主题
高级资深前端面试题 · Nuxt 性能优化
Nuxt 应用出现客户端数据瀑布，如何重构数据获取？
这道题不只考 Nuxt API 记忆，还考察你能否把渲染模式、服务端运行时、数据链路、性能指标和生产治理连起来。
面试官想考什么
- 你能否定义 Nuxt 能解决的问题和边界？
考察是否理解约定式全栈框架，而不是只会调用 composable。 - 你能否解释请求、渲染、数据和客户端接管的完整链路？
考察 SSR、hydration、payload、Nitro 和浏览器之间的因果关系。 - 你能否做生产级取舍？
考察缓存、部署、鉴权、可观测性、兼容性、成本和回滚意识。 - 遇到性能或线上故障能否定位？
考察是否有分段指标、实验验证和降级恢复方案。
一句话回答
text
把页面关键数据在服务端并行获取或聚合，减少组件层级串行请求，用稳定 async data key 和缓存共享结果。面试回答详解
这道题的高级回答不能停在“Nuxt 提供了一个 API”。应当说明它在构建期、Nitro 服务端、Vue SSR、客户端 hydration 和部署平台之间分别做了什么。
1. 并行请求
先画出请求依赖图，区分真正有依赖的请求和只是因为子组件 mounted 才开始的请求。可在页面级 useAsyncData 中并行 Promise.all，或由 Nitro BFF 聚合多个后端请求；重复数据用共享 key 或服务端缓存复用。低优先级模块延迟加载，避免让次要请求阻塞 SSR。优化后看 waterfall、TTFB、LCP 和总请求数，不能只看单接口耗时。
2. BFF 聚合
把页面关键数据在服务端并行获取或聚合，减少组件层级串行请求，用稳定 async data key 和缓存共享结果。 在 Nuxt 项目中通常要同时考虑服务端首屏、客户端接管、数据复用和错误边界，不能只看本地开发环境是否能运行。
3. 数据依赖图
- 服务端边界：私密配置、鉴权、请求上下文和服务端缓存不能错误地进入客户端 bundle。
- 数据边界：首屏必要数据、个性化数据和低优先级数据应有不同的获取与缓存策略。
- 性能边界：SSR、预渲染和 CSR 都有成本，必须结合 TTFB、LCP、INP、CLS、hydration 和业务指标判断。
- 部署边界：Node、Serverless、Edge 和静态托管的文件系统、内存、长连接和缓存能力不同。
可直接背诵的 30 秒回答
text
先画出请求依赖图，区分真正有依赖的请求和只是因为子组件 mounted 才开始的请求。可在页面级 useAsyncData 中并行 Promise.all，或由 Nitro BFF 聚合多个后端请求；重复数据用共享 key 或服务端缓存复用。低优先级模块延迟加载，避免让次要请求阻塞 SSR。优化后看 waterfall、TTFB、LCP 和总请求数，不能只看单接口耗时。扩展知识
Nuxt 请求与渲染链路
text
请求 -> Nitro 入口 -> middleware / route rules -> 页面数据获取 -> Vue SSR
-> HTML + payload -> 浏览器加载 JS -> hydration -> 客户端交互常见失败模式
- 服务端和客户端输出不一致，产生 hydration mismatch。
- 服务端数据请求重复执行，或 async data key 不稳定导致缓存失效。
- 把用户态页面放进公共缓存，造成数据串用户。
- 只优化 bundle，忽略 TTFB、上游请求、payload 和长任务。
- 依赖 Node 专属 API，部署到 Edge 或 Serverless 后运行失败。
面试官追问链
追问一：Promise.all 失败会不会拖垮整页？
- 考察点：是否能从 Nuxt 的抽象落到具体运行时。
- 回答方向：先说明默认机制，再补充请求边界、异常路径和验证指标。
追问二：什么时候不应该聚合后端请求？
- 考察点：是否理解框架能力和业务安全/性能边界。
- 回答方向：区分浏览器、Nitro、上游服务和部署平台的责任，不把所有问题都交给 Nuxt。
追问三：共享 async data key 有什么副作用？
- 考察点：是否具备生产治理能力。
- 回答方向：给出可观测、可回滚、可降级的处理方案，并说明如何用测试或线上指标验证。