在新手階段，我們很容易把成功執行當成終點
只要沒報錯、畫面有出來、功能能用
就會下意識覺得完成了

問題是，如果專案一變大、使用者一變多時，會出現問題

一. 效能不是優化，而是選擇

大多數效能問題，
不是因為寫得慢，而是因為一開始就選錯做法
例如：

• 每次使用者動一下，就重跑整個流程
• 明明只需要改一小部分，卻全部重新計算
• 事件發生得很密集，卻每次都完整執行
  這些都不是語法錯誤，而是沒有把時間當成成本

二. 實務錯誤：事件一來就全做

在實作時，很容易把邏輯寫成
只要事件發生，我就把該做的全部做完

在功能上完全正確，
但在使用者實際操作時，事件可能是連續爆發的
這段程式其實會被呼叫幾十次、甚至幾百次。

三. debounce / throttle 在實務上是在救什麼

這時候 debounce / throttle 的出現就很單純了
它們能夠做到限制「這段程式實際執行的次數」

例如：

• 使用者停下來後再搜尋
• 拖曳中不要每一瞬間都更新
• resize 結束後再重新計算

四. 實務判斷方式

之後在寫事件時，可以思考

• 這個動作會不會連續發生？
• 使用者真的在乎每一次結果嗎？
• 少跑幾次，畫面會不會更順？

如果答案是肯定的，
我們幾乎可以直接確定這裡就是 debounce / throttle 的使用點
只要能辨認出哪些程式跑太多次、哪些事件其實不用每次處理
後面再學任何效能技巧，都會變得很自然～