TanStack Query 跟 Zustand 到底差在哪？實務上我怎麼分工

在 React 專案裡，狀態管理一直是很容易變亂的地方。

一開始功能還少的時候，可能 useState 就夠了。

後來資料越來越多，頁面之間要同步、API 要快取、表格要篩選、登入狀態要共用，最後很容易變成：

「反正不知道放哪，就先丟進 store。」

這也是我以前看過不少專案會遇到的問題。

特別是 Zustand 很輕量、很好用，寫起來又直覺，所以很容易什麼都往裡面塞。

但後來我慢慢發現，不是所有狀態都適合放進 Zustand。

尤其是 API 回來的資料。

先講結論

我現在會這樣分：

簡單講：

Server State 交給 TanStack Query，Client State 才交給 Zustand。

這句話很常聽到，但真正寫專案時，難的是判斷「這個狀態到底是哪一種」。

什麼是 Server State？

Server State 指的是「真正來源在後端」的資料。

例如：

這些資料有幾個特性：

• 不是前端自己擁有的
• 可能會過期
• 可能被其他人或其他裝置改變
• 需要 loading / error / refetch
• 可能需要快取

這種資料如果全部丟進 Zustand，前期看起來沒問題，但久了會開始出現一些麻煩。

把 API 資料放進 Zustand 會發生什麼？

假設我們把文章列表放進 Zustand：

const usePostStore = create((set) => ({
  posts: [],
  isLoading: false,
  error: null,

  fetchPosts: async () => {
    set({ isLoading: true });

    try {
      const res = await fetch('/api/posts');
      const data = await res.json();

      set({
        posts: data,
        isLoading: false,
      });
    } catch (error) {
      set({
        error,
        isLoading: false,
      });
    }
  },
}));

這樣不是不能用。

但問題是，寫久之後你會開始自己處理一堆 TanStack Query 已經幫你處理好的事情。

例如：

結果 Zustand 會慢慢從「狀態管理」變成「自己手寫一套 API cache 系統」。

這時候維護成本就會上來。

TanStack Query 適合處理 API 狀態

同樣的文章列表，如果用 TanStack Query，大概會變這樣：

function usePosts() {
  return useQuery({
    queryKey: ['posts'],
    queryFn: fetchPosts,
  });
}

使用時：

const { data, isLoading, error, refetch } = usePosts();

它會直接幫你處理：

所以 API 資料放 TanStack Query，通常會比放 Zustand 清楚很多。

那 Zustand 還需要嗎？

需要，而且很好用。

只是它比較適合放「前端自己擁有的狀態」。

例如：

const usePostUiStore = create((set) => ({
  selectedPostId: null,
  isCreateModalOpen: false,

  setSelectedPostId: (id) => set({ selectedPostId: id }),
  openCreateModal: () => set({ isCreateModalOpen: true }),
  closeCreateModal: () => set({ isCreateModalOpen: false }),
}));

這種狀態不是從 API 來的，也不需要快取。

它只是畫面互動狀態。

這時候放 Zustand 就很合理。

實務上我會這樣分工

以一個文章列表頁來說，可能會有這些狀態：

如果這個條件需要分享網址，我會優先放 URL search params。

例如：

/posts?keyword=react&category=frontend&page=2

這樣重新整理、分享連結、上一頁下一頁都比較直覺。

如果只是畫面內部互動，例如 drawer 開關、目前選哪一列，就放 Zustand。

常見錯誤：把 filter 跟資料綁太死

我以前看過一種狀況是：

const usePostStore = create((set, get) => ({
  posts: [],
  keyword: '',
  category: 'all',

  fetchPosts: async () => {
    const { keyword, category } = get();

    const res = await fetch(
      `/api/posts?keyword=${keyword}&category=${category}`
    );

    const data = await res.json();

    set({ posts: data });
  },
}));

這樣寫一開始很方便，但後來會變得有點卡。

因為資料、條件、請求流程全部綁在一起。

當頁面變複雜時，很容易不知道是誰改了 keyword、誰觸發 fetch、資料什麼時候該更新。

我現在會比較偏向：

const { keyword, category } = usePostFilterStore();

const postsQuery = useQuery({
  queryKey: ['posts', { keyword, category }],
  queryFn: () => fetchPosts({ keyword, category }),
});

這樣分工比較清楚：

當 keyword 或 category 改變，queryKey 也會改變，TanStack Query 就知道要重新取得資料。

queryKey 很重要

TanStack Query 裡面，我覺得最重要的是 queryKey。

它不是隨便取一個名字而已，它代表這份資料的身份。

例如：

queryKey: ['posts'];

代表全部文章。

但如果有篩選條件，就應該把條件也放進去：

queryKey: ['posts', { keyword, category, page }];

這樣 TanStack Query 才知道：

React 分類第 1 頁

跟

Next.js 分類第 2 頁

是不同資料。

如果 queryKey 設計不好，很容易出現：

• 畫面顯示舊資料
• filter 改了但資料沒更新
• 不同頁面吃到同一份 cache
• mutation 後不知道要 invalidate 哪個 query

所以我會把 queryKey 當成資料流設計的一部分，而不是只把它當設定。

Mutation 後資料怎麼更新？

例如新增文章後，列表應該更新。

TanStack Query 通常會這樣處理：

const queryClient = useQueryClient();

const createPostMutation = useMutation({
  mutationFn: createPost,
  onSuccess: () => {
    queryClient.invalidateQueries({
      queryKey: ['posts'],
    });
  },
});

這樣做的意思是：

新增成功後，讓 posts 相關資料失效，下一次重新取得。

如果用 Zustand，就常常會變成手動更新陣列：

set((state) => ({
  posts: [newPost, ...state.posts],
}));

不是不能做，但如果列表有分頁、排序、篩選，就會越來越麻煩。

因為你要自己判斷這筆新資料到底該不該出現在目前列表。

所以 mutation 後是否要手動更新 cache，要看情境。

我自己的分工原則

我現在會用幾個問題判斷狀態要放哪：

1. 這份資料真正來源在哪？

如果來源是後端，就優先 TanStack Query。

如果來源是前端互動，就考慮 Zustand 或 useState。

2. 這份資料會不會過期？

會過期，就比較像 Server State。

例如文章、商品、使用者資訊、收藏清單。

3. 這份狀態需不需要被很多元件共用？

如果只是單一元件內部狀態，用 useState 就好。

不需要為了「統一管理」全部放進 store。

4. 這份狀態需不需要出現在網址上？

如果需要分享、重新整理保留、支援返回上一頁，我會優先放 URL。

5. 這份狀態是不是純 UI？

例如 modal、drawer、tab、selected row。

這種就很適合 Zustand。

實務上的簡單架構

我會盡量讓資料流長這樣：

URL / Zustand filters        ↓TanStack Query queryKey        ↓API request        ↓UI render

而不是：

Zustand store├── filters├── API request├── data├── loading├── error└── cache-like logic

第一種分工會比較清楚。

第二種一開始很快，但專案變大後，store 很容易變成大型雜物間。

Zustand 不是不好，是不要拿來做錯的事

我很喜歡 Zustand。

它簡單、彈性高、不太囉嗦，拿來處理 UI state 很舒服。

但也因為太好用，所以很容易濫用。

尤其在沒有明確規範的專案裡，最後常常會變成：

不知道放哪 → 放 Zustand跨元件要用 → 放 ZustandAPI 資料要共用 → 放 Zustandloading 要共用 → 放 Zustand

這樣久了，狀態管理會越來越難追。

真正的問題不是 Zustand，而是沒有先分清楚：

這是 Server State，還是 Client State？

總結

我現在會把 TanStack Query 跟 Zustand 當成兩種不同角色。

對我來說，好的狀態管理不是全部集中在同一個地方。

而是每一種狀態都有清楚的歸屬。

資料來源在後端，就讓 TanStack Query 處理。

互動狀態在前端，就交給 Zustand。

需要被網址記住的條件，就放 URL。

這樣做不一定是最炫的架構，但在實務專案裡，通常會更好維護，也更容易讓下一個接手的人看懂。