大文件为什么不适合 Base64？
什么时候才该用？

Base64 为什么会让文件变大

Base64 的核心原理是：每次取原始数据的 3 个字节（24 bit），拆成 4 组 6 bit，再用 64 个可打印 ASCII 字符（A–Z, a–z, 0–9, +, /）各表示一组。

结果就是：3 个字节变成 4 个字符，每个字符占 1 字节，体积增大到原来的 4/3 ≈ 133%。

如果原始数据字节数不是 3 的倍数，会补 = 填充到 4 的倍数，实际增幅略高于 33%。

举例：一张 5 MB 的图片，Base64 后约 6.7 MB；一个 100 MB 的视频，Base64 后约 133 MB——比原文件多传 33 MB。

浏览器转换大文件时为什么会卡

最常见的写法是 FileReader.readAsDataURL(file)。问题在于这个 API 的工作方式：

1. 1
   全量读入内存：整个文件一次性被读成 ArrayBuffer，例如 50 MB 文件就占用 50 MB 内存。
2. 2
   主线程上编码：Base64 编码在 JavaScript 主线程上执行，期间浏览器无法响应用户交互，页面卡死。
3. 3
   构建超长字符串：编码结果是一个巨大的字符串（50 MB 文件 ≈ 67 MB 字符串），JavaScript 的字符串是不可变的，构建过程涉及大量内存分配和复制。
4. 4
   内存峰値翻倍：原始 ArrayBuffer + Base64 字符串同时存在于内存，瞬时内存占用约为原文件的 2.3 倍　50 MB 的文件可以瞬间吃掉约 115 MB 内存。

三种方案：该选哪个？

不同场景有不同的最优解。以下是三种文件处理方案的典型适用情况：

文件大小参考边界

没有绝对的规定，但以下边界被大多数开发者遵循：

用 Web Worker 处理大文件 Base64

如果你确实需要在浏览器端对较大文件做 Base64 编码，把耗时操作放到 Worker 可以避免 UI 冻结：

self.onmessage = function(e) {
  const buffer = e.data            // ArrayBuffer（零拷贝转移）
  const bytes  = new Uint8Array(buffer)
  let binary   = ''
  const CHUNK  = 8192
  for (let i = 0; i < bytes.length; i += CHUNK) {
    binary += String.fromCharCode(...bytes.subarray(i, i + CHUNK))
  }
  const base64 = btoa(binary)
  self.postMessage(base64)
}

const worker = new Worker('/base64.worker.js')

input.addEventListener('change', async (e) => {
  const file   = e.target.files[0]
  const buffer = await file.arrayBuffer()

  // Transferable：零拷贝，buffer 所有权移交给 Worker
  worker.postMessage(buffer, [buffer])
})

worker.onmessage = (e) => {
  const base64 = e.data             // 编码结果
  console.log('data:...;base64,' + base64)
}

postMessage(buffer, [buffer]) 第二个参数是 Transferable 列表，ArrayBuffer 的所有权被零拷贝移交给 Worker，主线程的 buffer 变为空（长度为 0），避免内存翻倍。

快速决策：一句话判断

相关工具