React 19.2 cacheSignal Performance Tracks Activity API 完整教學

React 19 剛出的時候，大家的注意力都放在 Server Components 和 Actions 上。坦白說，19.0 到 19.1 的更新確實平淡無奇。但 19.2 不一樣——這次的三個新功能，每一個都直接解決了我在生產環境中遇到的真實痛點。

我花了兩週時間在一個中型專案上測試這些新功能，以下是我的深度體驗報告。

React 19.2 不是小更新

先快速列出 19.2 的重點變更：

cacheSignal：給 RSC（React Server Components）快取加上 AbortSignal 控制
Performance Tracks：在 Chrome DevTools 裡直接看到 React 的排程和渲染資訊
Activity API：隱藏元件時保留狀態，取代粗暴的條件渲染
useEffectEvent：穩定版釋出，終於不用再 hack useEffect 的依賴陣列
SSR Suspense Batching：Suspense boundary 的串流批次處理最佳化

看起來都是「小功能」，但合在一起，它們大幅改善了 React 應用的可觀測性和效能調優體驗。讓我一個一個拆解。

cacheSignal：RSC 快取的精確控制

如果你用過 RSC 的 cache() 函式，應該有感受到一個問題：快取的生命週期很不透明。你不知道快取什麼時候會過期，也沒有辦法主動讓它失效。這在開發階段問題不大，到了生產環境就很痛苦。

cacheSignal 引入了 AbortSignal 的概念來管理快取：

import { cache, cacheSignal } from 'react';
import { unstable_cacheLife as cacheLife } from 'next/cache';

async function fetchUserProfile(userId: string) {
  'use cache';
  cacheLife('hours');

  const signal = cacheSignal();

  const response = await fetch(`/api/users/${userId}`, { signal });

  if (!response.ok) {
    signal.abort();
    throw new Error('Failed to fetch user');
  }

  return response.json();
}

這段程式碼有幾個關鍵點。首先，cacheSignal() 回傳的 AbortSignal 跟快取的生命週期綁定。當快取過期或被手動清除時，signal 會自動 abort。反過來，你也可以在特定條件下手動 abort signal，強制快取失效。

這解決了我之前在做 TanStack Query 伺服器狀態管理時遇到的一個困擾——RSC 層的快取跟客戶端的查詢快取對不上。有了 cacheSignal，我可以在 RSC 層更精確地控制快取行為。

實際用途

最常見的場景是「有條件的快取失效」。比如，使用者更新了個人資料後，你想立刻讓所有引用這個使用者資料的 RSC 快取失效：

// 在 Server Action 中
async function updateProfile(formData: FormData) {
  'use server';
  await db.users.update(userId, formData);

  revalidateTag(`user-${userId}`);
}

Performance Tracks：DevTools 的渲染透視鏡

這是我個人最喜歡的新功能。如果你用過 Chrome DevTools 的 Performance tab，應該知道它可以錄製和分析頁面的效能資訊。但之前 React 的渲染資訊在 Performance tab 裡是一團混亂——你看到一堆匿名的函式呼叫，很難對應到具體的元件。

Performance Tracks 改變了這一切。React 19.2 會在 Performance recording 中加入專屬的 track，清楚標示：

每個元件的渲染時間和觸發原因
Concurrent Mode 的排程決策（為什麼某些更新被推遲）
Suspense boundary 的狀態變化
Transition 的開始和完成時間

在 Chrome DevTools 裡打開 Performance tab，你會看到新增的「React」track 分類。每一個渲染事件都帶有元件名稱、props 差異、以及觸發的 state 變化。

我用這個功能找到了一個困擾我們團隊好幾週的效能問題：一個深層嵌套的元件因為 context 更新導致不必要的重渲染，而這個 context 更新是由一個完全不相關的功能觸發的。之前用 React Profiler 看不出來，因為 Profiler 不會顯示觸發鏈。Performance Tracks 直接用時間線的方式把因果關係串起來，一目了然。

搭配 Next.js PPR 優化一起使用，你可以非常精確地看到哪些部分是靜態預渲染、哪些是動態串流的。

Activity API：取代條件渲染的新思維

這個功能的概念很簡單，但影響深遠。傳統上，我們隱藏一個元件的方式是條件渲染：

// 傳統做法：狀態會被銷毀
{isVisible && <ExpensiveComponent />}

// 或者用 CSS 隱藏：DOM 還在，效能浪費
<div style={{ display: isVisible ? 'block' : 'none' }}>
  <ExpensiveComponent />
</div>

兩種方式都有問題。條件渲染會銷毀元件狀態，下次顯示時得重新初始化；CSS 隱藏則是 DOM 元素一直在，白白佔用記憶體和佈局計算。

Activity API 提供了第三種選擇：

import { Activity } from 'react';

function TabContainer() {
  const [activeTab, setActiveTab] = useState('home');

  return (
    <div>
      <Activity mode={activeTab === 'home' ? 'visible' : 'hidden'}>
        <HomeTab />
      </Activity>
      <Activity mode={activeTab === 'settings' ? 'visible' : 'hidden'}>
        <SettingsTab />
      </Activity>
      <Activity mode={activeTab === 'profile' ? 'visible' : 'hidden'}>
        <ProfileTab />
      </Activity>
    </div>
  );
}

當 mode 設為 hidden 時，React 會：保留元件狀態和 DOM 結構、暫停所有 effect（類似 unmount 但不銷毀）、降低排程優先級到最低、在切回 visible 時立即恢復，無需重新渲染。

這對 Tab 切換、路由過渡、Modal 等場景來說是巨大的改善。我測試了一個有 5 個 Tab 的 dashboard，切換延遲從平均 180ms 降到了 12ms，因為不再需要重新掛載和初始化元件。

useEffectEvent：事件處理的正確姿勢

useEffectEvent 其實已經在 experimental 階段很久了，19.2 終於把它標記為穩定。它解決的問題很具體：useEffect 裡面需要用到最新的 props/state 值，但又不想把它們加到依賴陣列裡觸發 effect 重跑。

import { useEffectEvent } from 'react';

function ChatRoom({ roomId, theme }) {
  const onMessage = useEffectEvent((message) => {
    showNotification(message, theme);
  });

  useEffect(() => {
    const conn = createConnection(roomId);
    conn.on('message', onMessage);
    return () => conn.disconnect();
  }, [roomId]);
}

之前要達成同樣效果，你得用 useRef 來存最新值，再在 useEffect 裡面讀 ref。那段 boilerplate code 寫多了真的很煩。useEffectEvent 把這個 pattern 標準化了。配合 Biome 前端工具的 lint 規則，可以自動檢測應該用 useEffectEvent 的場景。

SSR Suspense Batching 改進

這是一個比較底層的優化，但對 SSR 效能影響很大。在 19.2 之前，每個 Suspense boundary 的 resolve 都會觸發一次獨立的 HTML 串流。如果頁面上有 10 個 Suspense boundary 幾乎同時 resolve，就會發 10 次串流。

19.2 引入了 batching 機制：如果多個 Suspense boundary 在同一個 microtask 內 resolve，它們會被合併成一次串流發送。這減少了 HTTP chunk 的數量，降低了網路開銷。

我在一個 SSR heavy 的電商頁面上測試，TTFB 沒有變化（因為第一個 chunk 還是立刻發），但 LCP 改善了約 8%，因為後續的 chunk 更有效率地傳輸了。

升級指南與注意事項

從 React 19.0/19.1 升級到 19.2 基本上是無痛的，沒有 breaking changes。但有幾個注意事項：

Performance Tracks 需要 Chrome 128+：舊版 Chrome 看不到 React 的 track 資訊
Activity API 目前標記為 experimental：API 可能會在後續版本微調，生產環境使用請評估風險
cacheSignal 只在 RSC 環境有效：如果你還沒用 Server Components，這個功能對你沒有意義
useEffectEvent 的 ESLint 規則要更新：舊的 exhaustive-deps 規則不認得 useEffectEvent，需要更新 eslint-plugin-react-hooks

# 升級指令
npm install [email protected] [email protected]

# 如果用 Next.js
npm install next@latest

# 更新 ESLint 插件
npm install eslint-plugin-react-hooks@latest