本文详解 Nuxt 3 useFetch 在动态路由（如 /pages/[slug]）中无法自动重请求的根本原因及三种可靠解法：利用 params/query 自动监听、显式 watch + refresh()、以及关键的 key 策略与页面元信息配置。
本文详解 nuxt 3 `usefetch` 在动态路由（如 `/pages/[slug]`）中无法自动重请求的根本原因及三种可靠解法：利用 `params`/`query` 自动监听、显式 `watch` + `refresh()`、以及关键的 `key` 策略与页面元信息配置。
在 Nuxt 3 中，useFetch 默认具备响应式重请求能力——但这一能力仅在明确声明依赖项时才被激活。许多开发者误以为只要 URL 字符串中拼接了 route.params.slug，useFetch 就会自动监听变化；实际上，由于 useFetch 接收的是求值后的字符串（即一次性快照），而非响应式引用，因此 URL 变化后不会触发重请求，导致 data 停留在 null 或旧值，pending 永远为 false。
✅ 正确做法一：使用 params 选项（推荐）
将动态参数以响应式对象形式传入 params 选项，Nuxt 会自动将其作为依赖追踪，并在参数变更时重新发起请求：
<!-- pages/pages/[slug].vue -->
<script setup>
const route = useRoute()
const { data, pending, error } = await useFetch('/api/pages', {
params: route.params // ✅ 响应式对象，自动监听 slug 变化
})
</script>
<template>
<div v-if="pending">Loading...</div>
<div v-else-if="error">Error: {{ error.data.message }}</div>
<div v-else>
<h1>{{ data?.title }}</h1>
<p>{{ data?.content }}</p>
</div>
</template>对应 API 路由（server/api/pages.get.ts）：
export default defineEventHandler(async (event) => {
const { slug } = getQuery(event)
// 示例：调用 WordPress REST API
const res = await $fetch(`https://your-wp-site.com/wp/v2/pages?slug=${slug}`)
return res[0] ?? null
})? 优势：简洁、零手动管理、符合 Nuxt 数据获取约定；params 内部会被序列化为查询参数，适用于 RESTful 场景。
✅ 正确做法二：使用 query 选项（适用于查询参数）
若需基于 ?slug=xxx 这类查询参数刷新，应使用 query 选项并绑定响应式计算属性：
<script setup>
const route = useRoute()
const slug = computed(() => route.query.slug as string | undefined)
const { data } = await useFetch('/api/page-by-slug', {
query: { slug } // ✅ 自动响应 slug 查询参数变化
})
</script>✅ 正确做法三：显式 watch + refresh（灵活控制场景）
当需要更精细的控制逻辑（例如节流、条件刷新、或组合多个响应式源）时，可手动监听并调用 refresh()：
<script setup>
const route = useRoute()
const slug = computed(() => route.params.slug)
const { data, pending, refresh } = await useFetch(
() => `/api/pages?slug=${slug.value}`, // ✅ 使用函数式 URL，支持响应式求值
{ key: `page-${slug.value}` }
)
// 显式监听 slug 变化并刷新（注意：需在 onMounted 后执行，避免服务端/客户端不一致）
onMounted(() => {
watch(slug, () => {
if (slug.value) refresh()
})
})
</script>⚠️ 注意事项：
- 不要在顶层直接拼接 slug.value 到字符串 URL：这会丢失响应性；
- key 必须唯一且稳定：建议使用 key: \page-\${slug.value}``，确保缓存隔离；
-
启用 definePageMeta 的 key 配置（可选但推荐）：防止页面复用导致状态残留：
definePageMeta({ key: (route) => route.params.slug // ✅ 让 Nuxt 路由系统识别该页需按 slug 重建实例 }) - 服务端渲染（SSR）兼容性：useFetch 在服务端会自动等待数据就绪；但 watch 仅在客户端生效，故 refresh() 调用需包裹在 onMounted 中。
总结
useFetch 不是“魔法”，其响应式刷新依赖你显式声明响应式依赖源。优先选用 params 或 query 选项，它们语义清晰、开箱即用；仅在复杂逻辑下辅以 watch + refresh()。同时，配合 definePageMeta.key 可彻底规避动态路由组件复用引发的状态错乱问题。遵循这三原则，即可让 useFetch 在任何动态场景下稳定、高效地工作。
