我是RQ的重度用户已经有一段时间了，由于架构问题永远不会有客观正确的答案，我可以亲自演示我所做的。
首先，我按域将所有查询和组件提取到API模块中，给定一个包含帖子、作者和评论的简单应用程序，我将拥有与这些导出对应的文件：

// apis/posts.js
export function useGetPosts() {}
export function useGetPost(postId) {}
export function usePutPost() {}
export function usePostPost() {}
export function useDeletePost() {}

// apis/comments.js
export function useGetComments(postId) {}
export function useGetComment(commentId) {}
export function usePutComment() {}
export function usePostComment() {}
export function useDeleteComment() {}

// apis/authors.js
export function useGetAuthors() {}
export function useGetAuthor(authorId) {}
export function usePutAuthor() {}
export function usePostAuthor() {}
export function useDeleteAuthor() {}

这些模块中的每一个都将在内部处理作为一个整体工作所必需的一切，比如useDeleteAuthor将有一个突变，并且还将在成功时修改该高速缓存，或者可能实现乐观更新。
每一个都有一个查询键系统，这样消费者（您的组件）就不必了解它们。

function MyComponent() {
  const posts = useGetPosts()
}

function MyOtherComponent() {
  const deletePost = useDeletePost()
}

尽量使API尽可能完整，但也不要忘记，例如，变异可以在调用站点上接受回调：

deletePost.mutate(payload, {
  onMutate: () => setState(false)
})

让我们假设你可以用它来关闭一个确认模态，比如在删除之前，像这样的东西并不属于API模块，所以我们只是把它作为一个本地回调函数提供给变异。
如上所述，没有正确的答案。肯定有一种观点认为应该反过来做，更多地使用搭配，把查询放在你正在使用它们的组件旁边。但如果你想分离，在我看来，这将是一个开始。
正如Ben在对你的问题的评论中所写的，RQ只是钩子，所以我同意试图把它放在“React之外”是荒谬的。

您是对的，简短的回答是React查询与清洁架构不兼容，并且根据经验，它会导致逻辑和组件之间的紧密耦合

我正在尝试的一种方法是在组件中直接使用查询，而不实现副作用，除非副作用是专门针对该组件的。
然后在我的逻辑层中，我将使用QueryObserver并订阅我需要的任何键的更改。

const observer = new QueryObserver(myQueryClient, {
   queryKey: ['key']
})
observer.subscribe(result => console.log(result))

在本例中，我在queryClient自己的文件中定义了它。
这样我就可以将逻辑从视图层中分离出来，但仍然使用react-query的工作方式。
请注意，这样，逻辑将仅在装载了查询函数已解析的组件时运行。
此外，subscibe函数只能在初始useQuery安装后调用。否则，您将得到“MissingqueryFn”错误。这不是理想的。甚至接近。