群友在一次字節的面試中，被要求實現 useToggle。

useToggle 表示兩個狀態的來回切換。

群友一想，這還不簡單，于是就咔咔一頓寫，兩三筆就把該功能實現了。

function useToggle(value: boolean) {
  const [state, setState] = useState(value)

  const toggle = () => {
    setState(!state)
  }

  return {state, toggle}
}

搞完之后，面試官看到代碼卻說：

不太對，組件重新渲染，導致這個 hook 重新執行了，狀態就變了。

這下直接給群友整不會了，咋回事？為什么字節面試官說的東西跟他理解的不一樣。百思不得其解之下，在面試之后又去研究了很多方案，最后實在沒想通，又跑到群里來討論。

那么問題來了，截圖中，群友口中所說的字節面試官的這種說法是否靠譜呢？

一、很顯然不靠譜

從功能實現的角度上來說，上面那一段代碼，其實是沒有任何的問題的。

當組件重新渲染時，hook 會不會重新執行？當然會。

但是 hook 重新執行，狀態會不會發生變化？不會。

這里我們討論的是由其他狀態的變化導致組件 re-render，從而導致 toggle 的狀態被重置或者變化。

在 React 中，hook 是基于閉包來實現，因此幾乎每個 hook 理論上都具有緩存能力。我們常用的這些 hook：useState、useRef useReducer useEffect useMemo useCallback 他們都有一些共性，那就是緩存能力。然后在語義上有一些差異。

面試官這樣的說法，很明顯是在學習的時候，跟許多人犯了同樣一個錯誤，只關注了他們差異的部分，而沒有關注他們共性的部分。

因此，在群友的這段實現中，如果由其他狀態引發的 hook 重新執行，useToggle 的狀態會被 useState 緩存，狀態本身的值不會發生變化。否則，React 的根基都要被動搖了。

那么面試官為什么要這樣說呢？

一種可能就是面試官本身在工作實踐中沒有正確理解 React 的 hook，并且過于依賴了 useMemo useCallback，忽視了其他 hook 的緩存能力導致了錯誤的解讀。

另外一種情況就是在沒有得到自己想要的答案時，自動切入了壓力測試環節，試圖通過否定候選人逼問出滿意的答案。或者通過壓力測試觀察候選人的知識面中更多的維度。

二、有其他實現嗎

有的。該群友找到了 ahook 的實現，代碼如下：

function useTgoggle2(value: boolean, reverseValue?: boolean) {
  const [state, setState] = useState(value)

  const actions = useMemo(() => {
    const reverseValueOrigin = reverseValue === undefined ? !value : reverseValue;

    const toggle = () => {
      setState(prev => {
        return prev === value ? reverseValueOrigin : value
      })
    }
    return toggle
  }, [])

  return {state, actions}
}

和他寫的版本相比，代碼看上去豐滿了許多。一看就很高端。

但是另他想不通的地方在于，使用了 useMemo 之后，和他寫的那個版本，有什么區別嗎？或者說，有什么好處嗎？

他的第一個解讀是，useMemo 因為緩存了函數，所以減少了函數的重復聲明。

這種理解對不對呢？錯。

許多人都會有這樣的誤解。事實卻是，useMemo useCallback 不會減少函數的聲明。

我們把匿名函數，換成一個有名字的函數，就能快速理解了。

function xxx() {
  const reverseValueOrigin = reverseValue === undefined ? !value : reverseValue;

  const toggle = () => {
    setState(prev => {
      return prev === value ? reverseValueOrigin : value
    })
  }
  return toggle
}

const actions = useMemo(xxx, [])

實際上在 useMemo 執行之前，函數 xxx 都會重新聲明。包括 useMemo 傳入的第二個參數的空數組，它也是被重新聲明的。

useMemo 控制的是賦值次數，而不是聲明次數。

既然這樣，又不能減少函數聲明次數，那 useMemo 的作用在哪里呢？

在這個案例中，他的作用就是：保持 actions 的引用穩定。當組件重新渲染時，actions 的引用不會因為 re-render 而發生變化。

這樣，當使用者將 actions 作為參數傳遞給其他組件時，可以保證 actions 的引用是沒有發生變化的。

const {state, actions} = useToggle(true)

...

<OtherComponent actinotallow={actions} />

那么這個時候，如果我們在聲明 OtherComponent 時使用了 memo，OtherComponent 就不會因為父組件的 re-render 而重新渲染。

這里需要明確的是，單獨使用 memo 是沒有用的。關于更具體的細節，在我們之前的性能優化章節中有詳細聊到。

當然實際上這里就涉及到另外一個問題的探討，我們是否應該在工具庫底層使用 useCallback 或者 useMemo 來緩存函數的引用呢？

實際上在付費群里我們曾經對這個問題也有過爭議。

我個人的觀點是：沒有必要。因為對于使用者而言，我們想要保證性能優化的目標達成，那么就必須同時使用 useMemo/useCallback + memo。他們兩的共同作用下，能減少函數的 re-render，從而達到性能優化的目的。

一種情況是，需要這樣做的場景很少。

另外一種情況是，這可能對使用者造成誤解。認為只需要 memo 就可以完成性能優化了。

這種優化方式不是完全無感的，他需要使用者配合另外一半。因此這就要求使用者必須完全了解工具庫的底層實現才可以完美的配合你。或者更聰明的使用者也不會關注你底層是怎么實現，他自己又單獨包裹一層 useMemo/useCllback。

三、面試時答案被否定

咋說呢，這個現象其實非常普遍。

很多人在面試的時候，特別是在面一些好團隊時，遇到這種情況都會很懵逼。被人否定之后就習慣性地懷疑自己的答案有問題。從而導致后面的回答因為緊張和自我懷疑陷入一種惡性循環，給人一種整場表現都很差的感覺。

有幾種不同的情況會出現這種局面。

有的面試官比較善于抓住候選人的缺點不停拷打，進而證明候選人能力不足。這其實違背了面試的本質。好的面試官反而更應該懂得如何挖掘候選人的優勢，而不是在候選人不擅長的點上反復糾纏。

當然，這也可以理解，現在越來越多的面試官會陷入這種困境，很大一部分原因是因為太多的求職者在簡歷、面試中夸大自己的能力，把本來不屬于自己的項目經歷包裝成自己的，面試官與求職者信任關系的破裂，是主要是的因素之一。

當然，還有一部分原因是因為需要挖掘別人的優勢對面試官本身的個人能力有非常高的要求，并不是每個面試官都具備這樣的能力。因此，在這種情況下，一個比較好的技巧和方式就是主動自己先明確好自己的優勢在哪里，并且在聊天過程中主動展示。

除此之外，也包括部分求職者，屬于是找了半天，渾身下上就沒可挖掘的優勢。

壓力測試。或者說，故意在面試過程中給求職者施加壓力。讓求職者認為自己在這場面試里表現得不好。哪怕有的面試官對求職者非常欣賞，也不會表現出來。

所以很多時候，有的人雖然自己拿到了 offer，但是自己都感覺非常意外，因為自我感覺確實面試表現不是很好，在這種情況下還能拿到 offer，實屬是萬萬沒想到。

當然，為什么要這樣做，不同的團隊有不同的原因，可能是為了看看別人在壓力環節下的表現，可能是為了更好的打壓薪資，或者是為了讓求職者更加珍惜這個工作機會等等。

但是壓力測試也不是每個面試官都能輕松拿捏的，經常容易玩崩，讓別人對你這里的面試體驗感覺非常差。

確實是求職者思路不對，回答錯了。這種情況下最好是能在面試官的引導下快速思考錯誤原因，并給出正確的解法。當然，如果實在不行，就直接承認自己確實這方面比較薄弱比較好。但是不少人為了補救，會多說很多不沾邊的內容，反而會錯得更離譜。

四、總結

許多人雖然掌握了某些知識，但是沒有構建完整的知識體系，因此在面對別人反問或者質問時會表現得非常慌亂。

完善自己的知識體系，對自己所表達的觀念和結論有篤定的判斷，可以避免在這種情況之下讓溝通往更壞的情況發展。