前端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再读取的设计模式，增强了代码的灵活性和可扩展性，方便处理异步操作和事件监听，提高了代码的可读性和可维护性，并优化了资源利用。
