旧浏览器中使用FileReader读取字节的兼容问题实际含义咨询

针对你提到的场景——通过HTML input获取File对象后，用FileReader读取前几个字节判断MIME类型，结合旧Android浏览器的两类兼容问题，我来逐个拆解实际影响：

1. 浏览器不支持FileReader的情况 #

这是最直接的硬限制：

• 当你执行new FileReader()时，会直接抛出ReferenceError，因为这个构造函数在浏览器环境中根本不存在。
• 实际场景里，用户选择文件后，你的文件类型校验逻辑会直接崩溃，要么触发未捕获的错误弹窗，要么完全无法执行后续步骤。
• 这种情况下，你没有办法在前端完成字节读取的操作，只能依赖后端进行MIME类型校验，或者提示用户升级到支持FileReader的浏览器版本。

2. 浏览器支持FileReader，但不支持File构造函数的情况 #

这种情况要先理清一个关键细节：

• 通过HTML input[type="file"]获取的img_file对象，在这类浏览器中通常是Blob对象（File是Blob的子类，旧浏览器往往先实现了Blob的基础功能，后续才添加File构造函数）。
• 而FileReader的核心读取方法（readAsArrayBuffer()、readAsBinaryString()等）本来就支持读取Blob对象，所以你读取文件前几个字节的操作可以正常执行。
• 这里需要注意：如果你的代码依赖了File对象特有的属性（比如file.name、file.lastModified），这些属性在Blob对象上可能不存在或不符合标准，但如果只是读取字节判断文件签名（比如JPG的FF D8开头、PNG的89 50 4E 47开头），这部分逻辑不受影响。
• 实际场景里，你的文件类型校验流程可以正常完成，不会因为File构造函数缺失而失败，只要你没有额外依赖File专属的特性。

额外兼容建议 #

• 为了让代码更健壮，可以先判断img_file instanceof Blob（因为File也是Blob的实例），确保读取逻辑能同时兼容Blob和File对象：

  if (img_file instanceof Blob && typeof FileReader !== 'undefined') {
    // 执行FileReader读取字节的逻辑
  } else {
    // 降级处理：提示用户或依赖后端校验
  }
  

• 对于完全不支持FileReader的浏览器，建议直接跳过前端校验，把文件上传到后端后由服务器判断MIME类型，避免用户体验受损。

内容的提问来源于stack exchange，提问作者Hassan Baig