非 React 使用者估計看了都要搖頭啊。一個破回調函數的運用，居然能折騰出來這么多事。一大堆文章都在探討如何使用它更合理。事實上確實如此，在 React 獨特的單向數據流刷新機制下，對于 useCallback 認知的逐漸深入實際上也代表著對 React 本身這個機制的理解更進一步，因此在你徹底消化 React 刷新機制之前，這個過程中的每一個知識點可能都有巨大的探討空間

前幾天我的一位學生跟我探討了一種 useCallback 的用法，他的想法是：當我們在封裝開源工具庫時，對自定義 hook 中暴露出來的鉤子函數使用 useCallback 緩存。因為我們并不確定使用者是否需要一個引用穩定的鉤子函數，他們有可能是需要的，因此用 useCallback 來包一層是有意義的。但是他并不確定這樣的做法是否合適，是否具備較大的正向收益。

那么我就借著這個案例，來跟大家探討一下，我們在 React 進階的過程中，使用 useCallback 的四個階段。

階段一：敬畏

這個時候你還是一個初學者，對 React 的理解還不夠深刻不夠全面，但是常常看到文章，或者聽別人說 useCallback 跟性能優化有關，可對于你而言，你并不是非常清楚它跟性能優化的具體關系在哪里，想知道，但不知道或者不夠確定，因此對這個 hook api 有一種敬畏之心，各個論壇里對于 useCallback 的介紹很多很嘲雜，但你不敢隨便用。

因此你很想去看看別人的代碼里，useCallback 是怎么用的，是在什么場景下使用的，但是想要看到別人的代碼也并不容易，因此你可能會在這個階段徘徊。

階段二：懂了

隨著學習的深入，你逐漸開始深入理解了 React 的單向數據流機制，也對 React 的使用更加熟練，知道 React 經常會存在許多 re-render，你終于搞懂了 useCallback 的使用場景，它結合 React.memo 能夠緩存組件，避免組件的冗余 re-render。

于是你在項目中大量的使用了他們，就像當初 PureComponent 一樣，你恨不得每個函數都用 useCallback 套一層，以確保自己的項目能最大限度減少 re-render，從而達到一個極致的性能體驗。

function App() {
  ...

  const clickHankler = useCallback(() => {
    ...
  }, [count])

  const onOpen = useCallback(() => {
    ...
  }, [])
  
  ...
}

但是不管你用還不用，是大量使用還是大量不使用，從頁面的運行結果中，都看不出來你這樣寫帶來了什么實質的提升，甚至你有可能在依賴項的使用上感到難受，因為閉包的影響導致實際運行結果跟你預想的有出入。但是你能明確感受到 re-render 次數減少了。因此這個階段你非常堅信自己達到了性能優化的目的。

直到一次偶然的面試中，你被面試官一個問題問得啞口無言：只用 useCallback 能達到減少 re-render 的次數嗎？為什么？

階段三：精通

聽了我的直播分享，徹底搞懂了 React 的底層 DIFF 機制，你發現原來在 React 底層機制的邏輯下，我們大量的緩存工作其實是沒有必要的。React.memo 也有不小的使用成本，有的時候他的損耗不一定比 re-render 更低，于是你懂得了如何在項目中合理的使用 useCallback + React.memo，一通優化下來，項目里的 useCallback 都被刪得差不多了，只在關鍵位置剩下幾個。

優化的結果很理想，re-render 的情況不僅沒有變多，項目還減負了，性能又得到了提升，你很開心很有成就感。心想我終于又有了成長，再次遇到上次那個面試官，我必定能吊打他。

階段四：貫通

你終于明白了 useCallback 只是一個非常普通的記憶函數。在 React hooks 特定的機制下記憶函數本身就被大量運用。React 的許多 hook 都有類似的記憶能力，useCallback 只是最普通的那一個，另外的 hook 都在記憶能力的基礎之上又添加了一些別的語義。

useState
useEffect
useLayoutEffect
useCallback
useMemo
useRef
useReducer
useSyncExternalStore
...

這個階段你不再特殊看待他，在你的知識結構里面你也不再特意的把他跟性能優化掛上勾，而是把他標記為一個記憶函數，他能夠保持一個函數的引用，當你在 React 這個不穩定的上下文環境中過，需要一個穩定的引用時，你才會使用 useCallback。

因此，當你在封裝一個開源工具庫時，你想到了你會對外拋出一個鉤子函數，但是你并不確定使用者會如何使用這個鉤子函數，使用者有可能會把他傳遞給子組件，此時如果鉤子函數引用不穩，那么就有可能導致子組件 re-render。

例如在我們前面學習自定義 hook 的文章中，我們封裝了一個 hook useFetch，代碼如下：

import { useState, useRef, useLayoutEffect } from 'react'

type API<T, P> = (param?: P) => Promise<T>

export default function useFetch<T, P>(api: API<T, P>) {
  const param = useRef<P>()
  const [list, setList] = useState<T>()
  const [error, setError] = useState('')
  const [loading, setLoading] = useState(true)

  function getList() {
    api(param.current).then(res => {
      setList(res)
      setLoading(false)
      setError('')
    }).catch(err => {
      setLoading(false)
      setError(err)
    })
  }

  useLayoutEffect(() => {
    loading && getList()
  }, [loading])

  return { 
    param, 
    setParam: (p: P) => param.current = p,
    list, 
    error, 
    loading, 
    setLoading 
  }
}

我們可以看到代碼里，在這個自定義 hook 中，返回了兩個鉤子函數 setLoading setParam。

為了驗證他們的引用是否穩定，我們在使用 useFectch 的組件中使用如下代碼來驗證函數的引用是否發生了變化。

useEffect(() => {
  console.log('setLoading')
}, [setLoading])

驗證結果非常神奇，setLoading 的引用居然非常的穩定。但對于此時的你來說，這并沒有什么值得奇怪的地方。因為他是直接從 useState 中獲取出來的。useState 本身就具備記憶能力，因此對于 setLoading 來說，我們不再需要想任何辦法來讓他的引用來保持穩定。

setParam 跟預期一樣，一點也不穩定，每次狀態變化，他的引用都會發生變化。因為在定義它的時候，每次都是新生成的函數給他賦值。

return { 
    param, 
+    setParam: (p: P) => param.current = p,
    list, 
    error, 
    loading, 
    setLoading 
  }

此時到了 useCallback 大展身手的時候了，我們使用 useCallback 包一層。

return { 
    param, 
-    setParam: (p: P) => param.current = p,
+    setParam: useCallback((p: P) => param.current = p, []),
    list, 
    error, 
    loading, 
    setLoading 
  }

再次驗證，發現引用果然變穩定了。nice。

但是你害怕這樣做有什么你沒想到的點，因為 useCallback 太善變了，所以你就跑來跟我溝通，想確定一下這樣子做到底能不能帶來很大的正向收益。

萬萬沒想到，我一開口就說：沒必要。

我引導你去看一下引用穩定的 setLoading 是如何使用的，你就去翻了一下代碼，結果一看，壞事了，setLoading 因為傳了一個參數，導致在使用的時候又套了一層函數。

代碼如下。此時 onClick 接收到的還是一個引用不穩定的匿名函數... setLoading 的引用白考慮了。

<Button
  className={s.button}
  onClick={() => setLoading(true)}
>

然后你又看了一眼 setParam 的使用，還是這么個情況。

<input
  className={s.input}
  placeholder="請輸入您要搜索的內容"
  onChange={(e) => setParam(e.target.value)}
/>

最后一想，發現好像 useCallback 又做了無用功。

至此，你徹底悟了。

就說總有一種不確定感，原來少考慮了一步。當自定義 hook 傳出來的 函數在執行時需要傳入參數時，就不得不在這個函數外面包一層匿名函數，再傳遞給子組件使用，如果它不需要參數，useCallback 才會發揮它的效果。

function useRouter() {
  const { dispatch } = useContext(RouterStateContext);

  const navigate = useCallback((url) => {
    dispatch({ type: 'navigate', url });
  }, [dispatch]);

  const goBack = useCallback(() => {
    dispatch({ type: 'back' });
  }, [dispatch]);

  return {
    navigate,
    goBack,
  };
}

const {goBack} = useRouter()

... 

<Child onBack={goBack}  />

當真是真是步步驚心啊。

你終于悟到了要結合實際使用的場景去考慮使用 useCallback 的準確時機，自此，融匯貫通成就達成。