主题
高级资深前端面试题 · Nuxt 原理与运行时
Nuxt 的 composable 如何做到 SSR 安全和请求上下文隔离？
这道题不只考 Nuxt API 记忆，还考察你能否把渲染模式、服务端运行时、数据链路、性能指标和生产治理连起来。
面试官想考什么
- 你能否定义 Nuxt 能解决的问题和边界？
考察是否理解约定式全栈框架，而不是只会调用 composable。 - 你能否解释请求、渲染、数据和客户端接管的完整链路？
考察 SSR、hydration、payload、Nitro 和浏览器之间的因果关系。 - 你能否做生产级取舍？
考察缓存、部署、鉴权、可观测性、兼容性、成本和回滚意识。 - 遇到性能或线上故障能否定位？
考察是否有分段指标、实验验证和降级恢复方案。
一句话回答
text
composable 不能把请求级数据放在模块级可变变量中，应通过 Nuxt app、event、useState 或显式参数获取当前请求上下文。面试回答详解
这道题的高级回答不能停在“Nuxt 提供了一个 API”。应当说明它在构建期、Nitro 服务端、Vue SSR、客户端 hydration 和部署平台之间分别做了什么。
1. current instance
服务端并发时同一个 Node 进程会同时处理多个请求，模块级 ref、缓存用户对象或单例 client 都可能串数据。Nuxt composable 应使用 useState 的稳定 key、useRequestEvent、useRuntimeConfig 或参数传递保存请求范围状态；第三方 SDK 若无请求安全性，要在 plugin 中按请求创建或只保存无状态 client。客户端和服务端共享的 state 必须可序列化并考虑脱敏。
2. useState key
composable 不能把请求级数据放在模块级可变变量中，应通过 Nuxt app、event、useState 或显式参数获取当前请求上下文。 在 Nuxt 项目中通常要同时考虑服务端首屏、客户端接管、数据复用和错误边界，不能只看本地开发环境是否能运行。
3. 并发隔离
- 服务端边界：私密配置、鉴权、请求上下文和服务端缓存不能错误地进入客户端 bundle。
- 数据边界：首屏必要数据、个性化数据和低优先级数据应有不同的获取与缓存策略。
- 性能边界：SSR、预渲染和 CSR 都有成本，必须结合 TTFB、LCP、INP、CLS、hydration 和业务指标判断。
- 部署边界：Node、Serverless、Edge 和静态托管的文件系统、内存、长连接和缓存能力不同。
可直接背诵的 30 秒回答
text
服务端并发时同一个 Node 进程会同时处理多个请求，模块级 ref、缓存用户对象或单例 client 都可能串数据。Nuxt composable 应使用 useState 的稳定 key、useRequestEvent、useRuntimeConfig 或参数传递保存请求范围状态；第三方 SDK 若无请求安全性，要在 plugin 中按请求创建或只保存无状态 client。客户端和服务端共享的 state 必须可序列化并考虑脱敏。扩展知识
Nuxt 请求与渲染链路
text
请求 -> Nitro 入口 -> middleware / route rules -> 页面数据获取 -> Vue SSR
-> HTML + payload -> 浏览器加载 JS -> hydration -> 客户端交互常见失败模式
- 服务端和客户端输出不一致，产生 hydration mismatch。
- 服务端数据请求重复执行，或 async data key 不稳定导致缓存失效。
- 把用户态页面放进公共缓存，造成数据串用户。
- 只优化 bundle，忽略 TTFB、上游请求、payload 和长任务。
- 依赖 Node 专属 API，部署到 Edge 或 Serverless 后运行失败。
面试官追问链
追问一：useState 和普通 ref 的区别？
- 考察点：是否能从 Nuxt 的抽象落到具体运行时。
- 回答方向：先说明默认机制，再补充请求边界、异常路径和验证指标。
追问二：为什么模块级单例在 SSR 危险？
- 考察点：是否理解框架能力和业务安全/性能边界。
- 回答方向：区分浏览器、Nitro、上游服务和部署平台的责任，不把所有问题都交给 Nuxt。
追问三：怎样让 composable 既支持 SSR 又支持 CSR？
- 考察点：是否具备生产治理能力。
- 回答方向：给出可观测、可回滚、可降级的处理方案，并说明如何用测试或线上指标验证。