React 筆記 - 為什麼 key 屬性這麼重要？

在開發 React 列表元件時，我們常常會遇到這個警告：

⚠️ Warning: Each child in a list should have a unique 'key' prop.

這個讓我們煩躁的小警告！但這不只是 React 在挑剔，我想來探討為什麼這個 key 屬性如此重要，以及一個錯誤的 key 如何在 user 操作過程中「炸裂」！😱

雖然只是警告，但其實關乎 元件狀態是否能正確保留。這篇筆記透過程式碼示範，幫助我們牢記 key 的重要性。

錯誤示範：使用 index 作為 key

當使用陣列索引 (index) 作為 key 時，看似沒問題，但一旦有插入、刪除或重新排序，輸入框的狀態會錯亂。

嚴重問題

新增或刪除項目後，index 全部重算，導致輸入框的狀態錯亂。
React 誤以為元件被替換 → 重新 mount → 輸入內容被重置。

實際情境

在 BadListExample 中，如果我們在列表最後一個輸入框（BadList Item C）輸入內容後，點擊「新增項目」，我們會在 Console 看到：

這是因為 React 把原本的最後一個項目（BadList Item C）當成新元件來處理。當我們用 index 當 key 時，只要列表有變動，index 就會改變，React 就會：

把舊的 BadList Item C 元件移除（unmount）。
建立一個新的 BadList Item C 元件，Console 會再印一次 log。
輸入框的內容會被清空，原本輸入的資料就不見了。

正確示範：使用唯一 ID 作為 key

使用資料中的唯一 ID，React 就能正確識別並保留狀態。

這樣做的好處很明顯：即使我們在列表中新增或刪除項目，原本輸入框裡的內容依然會被妥善保留，不會因為順序變動而消失或錯亂。元件的 useEffect 也不會因為 key 錯誤而被多次觸發，整體效能和狀態管理都變得更穩定可靠。

實際情境

在 GoodListExample 中，如果我們點擊「新增項目」，Console 的輸出會是：

這代表只有新增的那個項目被 mount，其他既有項目的狀態與 Console 輸出都保持不變。React 成功地透過唯一 ID 識別出原有元件，避免了不必要的重建與狀態丟失。

Key 值的來源建議

通常我們應該從資料庫回傳的結果取得穩定且唯一的 key 值，而不是在前端臨時生成。雖然可以使用像 uuid 這樣的 library 來產生 key，但要特別注意：如果 uuid 每次 render 都會重新生成，那麼 key 也會改變，React 就會誤以為需要重新掛載元件，導致狀態丟失與效能問題。

只有在 uuid 能與資料綁定並保持穩定時，才適合使用。換句話說，盡量避免在前端直接用 uuid 當 key，除非它和資料是一對一且持久的綁定。否則，不僅失去 key 的優勢，還可能造成額外的渲染成本。

結論

在 React 裡，key 的選擇真的很重要！記得千萬別用 index 當 key，這樣很容易讓狀態亂掉、畫面出包。最好的做法是用資料裡穩定又唯一的 id（或跟資料綁定的 uuid），這樣 React 才能聰明地追蹤每個元件，狀態也不會莫名其妙消失。總之，key 要選對，開發才會順順利利～

React 的 key，不只是個 prop，它是決定元件「身份」的關鍵。