Nuxt3 三种数据获取方式比较

Nuxt3 数据获取的核心挑战

• 同构渲染问题：Nuxt.js 支持服务端渲染(SSR)，这意味着代码会在服务器和客户端两个环境中执行。如果处理不当，可能导致数据在两端重复获取。

• 水合问题：服务端渲染的 HTML 需要在客户端"激活"（hydration），如果两端数据不一致会导致水合失败。

• 性能优化：减少不必要的网络请求，优化首屏加载时间。

Nuxt3 数据获取三剑客

$fetch

基础网络请求工具

$fetch是 Nuxt.js 基于ofetch库提供的全局网络请求工具，特点如下：

• 不会自动请求,必须显示调用

• 没有缓存,每次调用都会重新发起请求

• 若在onServerPrefetch() 中 手动调用,则可支持 SSR 阶段的数据请求

useFetch：智能数据获取

• 自动防止服务端和客户端重复请求

• 内置缓存机制

• 支持懒加载和手动刷新

• 提供加载状态跟踪

注意

1. 页面初始化数据获取

2. 需要 SSR 支持的数据加载

3. 需要自动缓存的数据请求

useAsyncData：精细控制的数据获取

• 可自定义查询逻辑

• 支持 Promise 组合

• 更灵活的数据处理

注意

1. 需要组合多个请求

2. 使用第三方数据层(如 CMS 等等)

3. 需要自定义数据处理逻辑

useFetch vs useAsyncData

SSR 首次加载

• 请求次数 服务端请求 1 次 客户端请求 0 次

• 原因 SSR 阶段已经由服务器获取数据并注入页面,客户端无需重复请求

客户端导航

如<NuxtLink>

• 请求次数 客户端请求 1 次

• 原因 属于 SPA 行为,组件在客户端挂载并触发数据请求

手动刷新(浏览器刷新)

• 请求次数 服务器端请求 1 次(SSR) 客户端请求 0 次

客户端导航下的请求

什么是客户端导航

(1) 用户通过<NuxtLink>,navigateTo()等方式从一个页面跳转到另一个页面

(2) 页面不会重新加载,浏览器地址变更但保持在 SPA 环境

特点分析

• 不触发 SSR,全在客户端完成组件加载和数据请求

• 更快的页面切换,首屏更流畅

• 仅仅更新<NuxtPage>区域,保持整体应用结构不变

控制行为的常用选项

server:false

• 禁止在 SSR 阶段发起请求

• 无论是否为首次访问,数据只在客户端获取

• 常用于仅在客户端可用的场景,如访问浏览器 API,本地存储,Cookie 等等

lazy:true

• (1) 延迟请求数据，直到页面真正挂载后才发起请求。

• (2) 虽然它也导致 SSR 阶段不发起请求，但其目的在于懒加载而非禁用。

• (3) 通常用于非关键性数据加载，提升首屏渲染性能。

immediate:false

• (1) 不自动发起请求，需手动调用 refresh() 触发。

• (2) 适合等待用户交互或条件满足时再发起请求的场景。

watch:[]

• (1) 精确控制数据依赖项。

• (2) 仅当指定的依赖发生变化时才重新发起请求，避免重复请求。

总结与建议

• 在 SSR 首屏优化方面，useFetch / useAsyncData 是最佳选择，结合默认行为即可实现良好性能。

• 若你希望完全跳过 SSR 请求，推荐使用 server: false； 如果只是想延迟请求以优化渲染，可以使用 lazy: true。

• immediate: false 和 watch 提供了灵活的手动控制方式，适合构建复杂交互或依赖变化场景

• 对于通用数据请求且无需依赖 Nuxt 生命周期控制的逻辑，$fetch 是更灵活但更原始的方式。