本文讲解 Vue Apollo Composable 中 useQuery 无法响应嵌套 reactive 对象内属性变更的根本原因，并提供基于 reactive 变量对象的标准化解决方案，确保分页、过滤等多维参数变更均能触发正确且可维护的 GraphQL 请求。
本文讲解 vue apollo composable 中 `usequery` 无法响应嵌套 reactive 对象内属性变更的根本原因，并提供基于 `reactive` 变量对象的标准化解决方案，确保分页、过滤等多维参数变更均能触发正确且可维护的 graphql 请求。
在使用 Vue Apollo 的 useQuery 组合式函数时，一个常见却容易被忽视的问题是：当查询变量（variables）由多个独立的 reactive 对象拼接而成时，useQuery 并不会自动追踪其深层响应式变化。正如问题中所示，filters.verified 虽被声明为 reactive({ verified: true })，但当它作为 variables 配置项的一部分（即 { filters: { verified: { value: filters.verified } } }）传入 useQuery 时，Apollo 内部仅对传入的 初始对象引用 做浅层响应式监听——而 filters.verified 的更新并不会触发该顶层变量对象的 set 拦截，因此 useQuery 无法感知变更，导致网络请求始终携带旧值（如 value: true），即使控制台日志已显示新值。
✅ 正确做法是：将整个 variables 对象统一声明为一个 reactive 实例，使所有查询参数（包括分页、过滤、排序等）共用同一响应式上下文：
import { reactive } from 'vue'
import { useQuery } from '@vue/apollo-composable'
import gql from 'graphql-tag'
// ✅ 单一 reactive 变量对象 —— 所有字段变更均可被 useQuery 自动捕获
const variables = reactive({
pagination: {
limit: 50,
skip: 0
},
filters: {
verified: {
condition: 'EQUAL',
value: true // 初始值
}
}
})
const { result, error, loading, refetch } = useQuery(
gql`
query GetMatches($pagination: PaginationInput, $filters: matchFilterInput) {
getMatches(pagination: $pagination, filters: $filters) {
_id
category
// 其他字段...
}
}
`,
variables, // ? 直接传入 reactive 对象（非解构后的普通对象）
{
fetchPolicy: 'cache-and-network',
notifyOnNetworkStatusChange: true
}
)
随后，所有业务逻辑只需直接修改 variables 的嵌套属性，即可触发自动 refetch：
// 分页操作 —— 自动重请求，携带当前 filters.verified 值
const nextPage = () => {
variables.pagination.skip += 50
}
const prevPage = () => {
if (variables.pagination.skip > 0) {
variables.pagination.skip -= 50
}
}
// 过滤切换 —— 同样自动生效，无须手动 refetch
const handleRPR = () => {
variables.filters.verified.value = true
}
const handleRPRs = () => {
variables.filters.verified.value = false
}
⚠️ 注意事项：
- ❌ 避免将 variables 拆分为多个 reactive 对象再合并（如 filters 和 state.pagination 分开定义后组合），这会破坏响应式链路；
- ✅ 若需动态增删过滤条件（如添加 status 字段），仍应通过 variables.filters 对象进行赋值，而非替换整个 filters 引用（否则会丢失响应式连接）；
- ? refetch() 在此模式下仍可用，但通常无需显式调用——只要修改的是 variables 的响应式属性，useQuery 就会在下一个微任务中自动发起新请求；
- ? 如需更精细控制（例如防抖过滤、条件性启用某 filter），可配合 watch + refetch()，但仍应以 variables 为唯一数据源，保持单向数据流。
总结来说，useQuery 的响应式依赖于 变量对象本身的响应式代理是否被完整保留。将全部查询参数封装进同一个 reactive() 是保障变更可追踪、逻辑可预测、维护可持续的最佳实践。这一模式不仅解决了 filters.verified 不更新的问题，也为未来扩展复杂筛选、多级联动（如“仅当 verified=true 时才启用 category 筛选”）奠定了坚实基础。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
