一、Nuxt3 中不同数据获取方式的请求行为对比

（一）总结：请求行为一览

• useFetch 和 useAsyncData 是 Nuxt 推荐的数据获取 API，自动集成 SSR 与客户端导航流程。
• $fetch 是更底层的请求方法，不具备自动触发、缓存等集成功能。
• 请求行为可通过 server、lazy、immediate、watch 等选项精细控制。
• server 和 lazy 在行为上都可实现“跳过 SSR 请求”，但语义和应用场景不同。

（二）各数据获取方法请求行为分析

1. useFetch 和 useAsyncData

• SSR首次加载

  • (1) 请求次数：服务端请求 1 次，客户端请求 0 次。
  • (2) 原因：SSR 阶段已由服务器获取数据并注入页面，客户端无需重复请求。

• 客户端导航（如 <NuxtLink>）

  • (1) 请求次数：客户端请求 1 次。
  • (2) 原因：属于 SPA 行为，组件在客户端挂载并触发数据请求。

• 手动刷新（浏览器刷新）

  • (1) 请求次数：服务端请求 1 次（SSR），客户端请求 0 次。

2. $fetch

• (1) 不会自动请求，必须显式调用。
• (2) 没有缓存，每次调用都会重新发起请求。
• (3) 若在 onServerPrefetch() 中手动调用，则可支持 SSR 阶段的数据请求。

（三）客户端导航下的请求行为特点

1. 什么是客户端导航？

• (1) 用户通过 <NuxtLink>、navigateTo() 等方式从一个页面跳转到另一个页面。
• (2) 页面不会重新加载，浏览器地址变更但保持在 SPA 环境中。

2. 特点分析

• (1) 不触发 SSR，全在客户端完成组件加载和数据请求。
• (2) 更快的页面切换，首屏更流畅。
• (3) 仅更新 <NuxtPage /> 区域，保持整体应用结构不变。

（四）控制请求行为的常用选项

1. server: false

• (1) 禁止在 SSR 阶段发起请求。
• (2) 无论是否为首次访问，数据只在客户端获取。
• (3) 常用于仅在客户端可用的场景，例如访问浏览器 API、本地存储、Cookie 等。

2. lazy: true

• (1) 延迟请求数据，直到页面真正挂载后才发起请求。
• (2) 虽然它也导致 SSR 阶段不发起请求，但其目的在于懒加载而非禁用。
• (3) 通常用于非关键性数据加载，提升首屏渲染性能。

📝 server: false vs lazy: true 对比

3. immediate: false

• (1) 不自动发起请求，需手动调用 refresh() 触发。
• (2) 适合等待用户交互或条件满足时再发起请求的场景。

4. watch: []

• (1) 精确控制数据依赖项。
• (2) 仅当指定的依赖发生变化时才重新发起请求，避免重复请求。

二、总结与建议

• 在 SSR 首屏优化方面，useFetch / useAsyncData 是最佳选择，结合默认行为即可实现良好性能。
• 若你希望完全跳过 SSR 请求，推荐使用 server: false；
  如果只是想延迟请求以优化渲染，可以使用 lazy: true。
• immediate: false 和 watch 提供了灵活的手动控制方式，适合构建复杂交互或依赖变化场景。
• 对于通用数据请求且无需依赖 Nuxt 生命周期控制的逻辑，$fetch 是更灵活但更原始的方式。