Nuxt SSR：首屏、注水与请求作用域

本系列承接Vue响应式和Vue Router导航，采用Nuxt4课程目录，研究同一页面在服务器与浏览器中的两次工作。示例未执行；所有运行步骤与现象都是未来验收预期，不是构建或浏览器记录。先读本篇与数据边界，再读完整源码与排障。

Nuxt的SSR和SPA首屏有什么区别

Nuxt的SSR和SPA首屏有什么区别？SSR在服务器生成含课程内容的HTML，SPA通常先交付页面外壳，再由浏览器执行脚本读取课程。两者都可以在后续使用客户端导航；SSR不等于每次点击都重新下载整页，也不等于浏览器不需要JavaScript。目录首页与详情首屏需要公开内容，本例保留默认SSR；内网交互面板若只关心登录后操作，则需衡量服务器成本再选模式。

对这个三条课程目录，判断SSR的证据应是原始HTML出现课程标题，而非浏览器最终DOM出现标题。静态生成可把相同公开内容提前输出，但本例欢迎语依赖请求语言，整页不能未经分离就预渲染成一份。内容可见性、可交互时间、服务器响应时间是不同指标，不能把SSR写成自动更快或自动解决SEO。原理依据见Vue SSR指南。

Nuxt的hydration为什么需要相同初始数据

Nuxt的hydration为什么需要相同初始数据？hydration让浏览器接管服务器已经输出的HTML并绑定事件；初始数据必须描述同一棵组件树。服务器生成false的紧凑偏好，浏览器第一次渲染也从payload恢复false；用户勾选后才更新。若浏览器先读localStorage=true，首轮树就不同，造成不匹配，而不是一次正常的用户操作。

目录不在模板调用Date.now或Math.random，不做服务器和浏览器各自的时区格式化，也不把服务器取不到的window宽度当首屏条件。应优先用可复现输入；确实依赖浏览器环境的增强，可挂载后更新或隔离为ClientOnly，并提供有意义的回退。隐藏告警或全站关闭SSR会遮住原因，不能替代检查HTML结构和数据来源。

Nuxt的useState怎样避免跨请求状态污染

Nuxt的useState怎样避免跨请求状态污染？useState在setup调用时由Nuxt请求上下文管理，以稳定键恢复序列化状态；模块顶层可变ref却可能随服务器进程被多个请求共享。useReadingPreference返回useState('catalog:compact:v1',()=>false)，没有把返回值存进模块变量，因而每个SSR请求从独立布尔值开始。客户端同一应用导航仍共享这个偏好，硬刷新又是新请求。

server/data只共享冻结的公开课程，所有欢迎语在handler内部读取event生成。不能把“上次语言”“当前用户”赋给模块顶层对象，也不能把useState理解成持久数据库。键负责标识同一状态，不能把不同用途误用同一键；敏感信息即便隔离正确，也不应进入可序列化页面状态。依据见Nuxt状态管理和useState。

Nuxt教学项目为什么固定4.2.2和Node22.14.0

Nuxt教学项目为什么固定4.2.2和Node22.14.0？4.2.2是已发布版本，其官方manifest要求Node ^20.19.0或>=22.12.0，Node22.14.0属于兼容范围；精确固定直接依赖让读者明确学习对象。项目同时固定Vue3.5.25与Router4.6.3，与该Nuxt标签所列范围一致。此选择不宣称版本最新、无安全问题，也没有验证本机安装结果。

本例使用Nuxt4的app目录结构，server与fixtures在项目根。没有lock意味着传递依赖仍可能变化，compatibilityDate也不能替代lock或保证所有平台产物一致。官方证据：Nuxt发布、标签manifest、Node发布。

练习：两次请求与一次点击

A携带en-US请求首页，B携带zh-CN同时请求。A勾选compact后通过NuxtLink进入详情，B随后刷新。画出fixture、welcome、compact各自属于哪个生命周期，并指出把compact提到模块顶层的后果。

参考答案（推演，未执行）

公开冻结fixture属于进程可共享输入；welcome属于各自event与响应；compact属于各自SSR上下文并进入各自payload。A客户端导航保留true，B刷新仍从false初始化。模块顶层可变compact可能使A影响B；即使加固定useState键，也不能把结果放入共享模块变量。没有任何用户身份或跨设备同步功能。