前端FileReader：實例化優先于讀取的原因詳解
在前端開發中，使用FileReader API處理文件上傳是常見操作。然而，為什么需要先實例化FileReader對象，再進行讀取？本文將深入探討這種設計模式背后的原因。
示例代碼展示了利用FileReader讀取文件并顯示圖片的流程：先實例化FileReader，再調用readAsDataURL方法讀取文件，最后通過load事件監聽器獲取結果并顯示圖片。
那么，為什么不直接new FileReader(file)并讀取？主要原因如下：
立即學習“前端免費學習筆記（深入）”；
1. 靈活擴展與事件監聽: FileReader的設計允許通過事件監聽器（load、progress、Error、abort）處理文件讀取的不同階段。預先實例化FileReader對象，方便添加多個事件監聽器，實現更復雜的邏輯，例如：顯示讀取進度條，或提供取消讀取功能。直接在構造函數中讀取，則難以添加這些監聽器。示例代碼中，progress事件監聽器展示了如何顯示讀取進度，abort()方法則演示了取消讀取操作。這些功能都依賴于預先實例化的FileReader對象。
2. 避免異步操作與構造函數沖突: JavaScript的異步特性使得在構造函數中直接進行文件讀取變得復雜。JavaScript構造函數不允許使用async關鍵字，而文件讀取是異步操作。在構造函數中進行讀取會使代碼難以理解和維護。將讀取操作放在readAsDataURL等方法中，更清晰地表達異步操作流程，避免與構造函數沖突。
3. 單例復用與資源優化: 通過預先實例化FileReader，可以復用同一個實例讀取多個文件，減少對象創建次數，提高效率。
4. 面向對象編程思想: FileReader API的設計遵循傳統的基于面向對象編程（OOP）的API設計方式。先創建對象，再調用對象方法完成操作，符合大多數開發者的編程習慣，也更易于理解和維護。XMLHttpRequest也采用類似的設計模式。雖然現在有更簡潔的fetch API，但FileReader的設計模式仍然合理有效。
總結: 先實例化FileReader再讀取的設計模式，增強了代碼的靈活性和可擴展性，方便處理異步操作和事件監聽，提高了代碼的可讀性和可維護性，并優化了資源利用。
