1. 一张图片在浏览器里到底有几个身子先把Blob、ArrayBuffer、base64的关系捋直刚接触图片处理的前端八成都会被同一件事绕晕同样是一张图片为什么有的地方要传文件对象有的地方要传一串以data:image/png;base64,开头的长字符串还有的地方张口就要二进制流。我最早做图片上传预览时代码里同时出现了File、Blob、FileReader、toDataURL、Uint8Array五种东西跑是跑通了但只要需求一变——比如要压缩、要加水印、要分片上传——立刻推倒重来。根子在于JS里图片从来不是一个东西而是一份字节数据在不同容器里的不同包装。真正的像素和编码信息只有一份就是那串字节Blob、File、ArrayBuffer、base64字符串都是这串字节的不同外壳。你把外壳认清楚了图片转base64二进制流转base64这类需求就只剩下几个API的排列组合。我平时用一句话给新人解释字节是米Blob是装米的袋子还贴着这是JPG的标签ArrayBuffer是一排整齐的格子每格正好放8位Uint8Array是给这排格子配的编号尺base64是把米磨成粉再用64种字符重新捏成能塞进文本协议的团子。磨成粉体积会变大但好处是能混进只认文本的通道里走。1.1 四种形态各自的脾性和适用边界先把它们摆在台面上对比后面所有代码都从这张表里长出来形态本质能不能直接塞进JSON体积典型来源/用途File带文件名和修改时间的Blob不能原样input typefile、拖拽、粘贴Blob不可变的字节块 MIME类型不能原样canvas.toBlob、fetch().blob()、切片上传ArrayBuffer/Uint8Array裸内存视图不能原样加解密、编码转换、手动拼字节base64字符串文本编码后的字节能约原体积的 4/3内联图片、CSS背景、纯文本接口这张表里最关键的一列是能不能直接塞进JSON。很多后端接口的字段是字符串类型图片只能以base64过去而表单上传走的是multipart/form-data天生就吃Blob。选哪种形态本质上是被传输通道决定的不是被你的喜好决定的。我见过有人把5MB的图片转成base64塞进JSON POST前端卡了两秒后端网关直接413——问题不在代码写错而在通道选错了。还有一个容易被忽略的点这四种形态之间不是任意互转都有现成API。File → base64有FileReaderBlob → ArrayBuffer有blob.arrayBuffer()现代浏览器或FileReader.readAsArrayBuffer但base64 → Blob就得你自己先解成Uint8Array再包一层。链条中间断在哪一环决定了你要不要手写转换函数。1.2 为什么二进制流这个词在JS里其实有点含糊后端同事说给我二进制流前端同事说我拿到的是二进制流两边说的往往不是一回事。JS语境下它至少指三种东西Blob/File、ArrayBuffer、以及atob返回的那种每个字符码位小于256的字符串。第三种最坑它长得像普通字符串length也正常但你没法直接传给new Blob()。我现在的习惯是沟通时直接说类型名不说二进制流。我这给的是Blob、我需要Uint8Array一句话省掉半小时扯皮。写代码时也保持这个习惯函数签名里明确写function toBase64(input: Blob | ArrayBuffer): Promisestring比注释写十行都管用。真正的新手门槛不在API数量而在于每一次转换都可能是有损的、异步的、或者带额外开销的。toDataURL会重新编码JPEG质量掉一档canvas会丢EXIF方向信息base64让体积涨三分之一。把这些代价提前想清楚你写出来的图片处理代码才不会是能跑但迟早出事的那种。2. 图片转base64的四条路FileReader、canvas、fetch、手动拼装需求里最常见的一句话是把用户选的图片转成base64传给后端。实现路径至少有四条长短不同、代价不同适用的场景也完全不一样。我按从最省事到最可控的顺序排一遍每条都说说它会在什么地方咬你一口。2.1 FileReader.readAsDataURL最稳但别把它当压缩工具拿到File对象之后最直接的写法就是function fileToBase64(file) { return new Promise((resolve, reject) { const reader new FileReader(); reader.onload () resolve(reader.result); // 完整 data URL reader.onerror () reject(reader.error); reader.readAsDataURL(file); }); }它返回的是data:image/jpeg;base64,/9j/4AAQ...这样一整串前缀和内容是在一起的。这一点必须记牢后端说只要base64内容不要前缀你得自己split(,)[1]。我见过最典型的事故就是前端把带前缀的字符串直接存库前端自己渲染时又拼了一次data:image/jpeg;base64,结果图片永远出不来排查半天。readAsDataURL的另一个特点是它不做任何重编码。原图3MB转出来的base64就是4MB出头像素、质量原封不动。很多人以为它是压缩函数转完发现请求还是超时白忙一场。它是编码工具不是压缩工具这两件事必须分开想。还有个小细节reader.result的类型是string | ArrayBuffer | nullTS里不窄化会报错。稳妥写法是断言或者判断typeof reader.result string。另外FileReader是异步的一次只能读一个批量处理时别用同一个实例重复readAsDataURL——我在一个多图上传的页面里这么干过结果先读的结果被后读的覆盖只有最后一张是对的。2.2 canvas.toDataURL顺手把压缩和转码一起做了要走压缩就得请出canvasasync function fileToCompressedBase64(file, maxSide 1600, quality 0.82) { const bitmap await createImageBitmap(file); const scale Math.min(1, maxSide / Math.max(bitmap.width, bitmap.height)); const w Math.round(bitmap.width * scale); const h Math.round(bitmap.height * scale); const canvas document.createElement(canvas); canvas.width w; canvas.height h; const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0, w, h); bitmap.close(); // 及时释放 return canvas.toDataURL(image/jpeg, quality); }toDataURL(mime, quality)的两个参数里quality只对image/jpeg和image/webp生效对PNG完全无效——这点我踩过一直以为压缩没起作用是因为参数没传对其实是输出格式写成了PNG。PNG是无损格式没法用质量参数换体积要压PNG只能靠缩小尺寸或者换格式。用createImageBitmap而不是new Image()是我的个人偏好前者返回Promise代码是线性的后者要挂onload稍微复杂一点就会写成回调地狱。更实际的好处是createImageBitmap支持{ imageOrientation: from-image }选项能按EXIF方向自动摆正——手机拍的照片横竖颠倒问题在这里能顺手解决。代价也很明确canvas转出来的图必然会重新编码。JPEG会掉质量带透明通道的PNG转成JPEG后透明区域会变黑。如果业务要求原图不失真这条路直接排除老老实实用readAsDataURL。2.3 fetch配blob/arrayBuffer处理远程图片的标准姿势处理用户上传的文件用FileReader处理已经在服务器上的图片就得用fetchasync function remoteToBase64(url) { const res await fetch(url); if (!res.ok) throw new Error(HTTP ${res.status}); const blob await res.blob(); return await blobToBase64(blob); } function blobToBase64(blob) { return new Promise((resolve, reject) { const reader new FileReader(); reader.onload () resolve(reader.result); reader.onerror reject; reader.readAsDataURL(blob); }); }这段代码本身没问题问题几乎全在跨域上目标图片所在的服务器必须放行否则res.blob()直接抛错。更隐蔽的坑是你把跨域图片画到canvas上之后toDataURL会抛SecurityError也就是所谓的canvas污染。这条我在第6节会展开因为它值得单独讲。顺带说一句fetch拿到的blob自带MIME类型转成data URL时前缀是对的但如果你用response.arrayBuffer()再手工拼前缀就得自己判断类型判错了后端可能把JPG存成.bin。2.4 手动从ArrayBuffer拼base64为了搞懂原理也为了特殊场景第四条路最原始拿到字节数组自己编码。它一般用不上但有两种情况救过我的场——一是在Worker里配合fetch做流式处理二是需要在编码前对字节做手脚比如加解密、拼接自定义文件头。理解它其实只需要记住一个事实base64是把每3个字节24位切成4组6位再用64个可打印字符表示。所以编码后的长度永远是Math.ceil(n / 3) * 4不足的部分用补齐。这个公式解释了为什么体积会涨到约4/3也解释了为什么32字节的摘要编码出来是44个字符。心里有这个换算关系你看到一段base64就能估出原始大小排查问题时特别有用。至于真正的编码动作浏览器里靠btoa但它有一堆限制这是下一节的主角。3. 二进制流和base64互转btoa和atob那两个看着能用其实不能直接用的函数btoa和atob的名字来自Binary to ASCII和ASCII to Binary看起来正好就是我们要的东西。但直接拿它们处理图片字节数组十有八九会翻车而且报错信息还不告诉你为什么。3.1 atob返回的是二进制字符串不是Uint8Array先看解码方向。很多人以为atob出来的是可以直接用的字节数组实际它返回的是一个每个字符的码位都在0~255之间的普通字符串。它看起来像字符串length也对但你不能直接把它塞进new Blob()得先转成Uint8Arrayfunction base64ToUint8Array(base64) { const binary atob(base64); // 二进制字符串 const len binary.length; const bytes new Uint8Array(len); for (let i 0; i len; i) { bytes[i] binary.charCodeAt(i); } return bytes; }这里有个性能细节值得留意用Uint8Array.from(binary, c c.charCodeAt(i))写法更简洁但对几MB的数据from配合回调的开销明显比显式for循环大。我实测过一张4000×3000的照片显式循环大约快20%~30%差距不算致命但在批量处理场景里能感觉到。再往下走一步就能得到Blobfunction base64ToBlob(base64, mime image/jpeg) { const bytes base64ToUint8Array(base64); return new Blob([bytes], { type: mime }); }注意mime必须你自己传。base64本身不携带类型信息——/9j/开头是JPEG、iVBOR开头是PNG这些都得靠嗅探或者从原data URL里截前缀。忘了传就用默认值后端存下来的文件扩展名和真实内容对不上某些老系统直接拒绝解析。3.2 btoa遇到码位大于255的字符会直接抛异常编码方向的坑更硬。btoa只接受码位都在0~255范围内的字符串一旦有中文、emoji、或者任何超出Latin-1的字符立刻InvalidCharacterError。所以下面这行看起来天经地义实际必崩btoa(我的图片); // 抛错处理图片字节数组时只要你的数组是Uint8Array并且逐字符转成了字符串btoa是安全的因为每个码位确实都在255以内。真正危险的是把字符串直接编码的场景。稳妥做法是先做UTF-8编码再编码base64function utf8ToBase64(str) { const bytes new TextEncoder().encode(str); // 先转UTF-8字节 let binary ; const chunk 0x8000; // 分块见下节 for (let i 0; i bytes.length; i chunk) { binary String.fromCharCode.apply(null, bytes.subarray(i, i chunk)); } return btoa(binary); }顺便提醒btoa编码的是字符串所以它处理的是字节已经变成字符串之后的数据不是字节数组本身。这个概念错位是新手最常见的理解偏差。3.3 分块是必须的一次性展开大数组会爆栈String.fromCharCode.apply(null, bytes)这种写法在处理小数组时很优雅但数组一长就会撞上Maximum call stack size exceeded——apply把每个元素当参数传参数太多直接把调用栈压塌。阈值不固定各浏览器不同我遇到过的临界点在10万到15万字节之间大概对应80KB~120KB的图片数据。所以只要是字节数组转字符串的操作我统统加分块function uint8ArrayToBase64(bytes, chunkSize 0x8000) { let binary ; for (let i 0; i bytes.length; i chunkSize) { const sub bytes.subarray(i, i chunkSize); // subarray 不复制内存 binary String.fromCharCode.apply(null, sub); } return btoa(binary); }0x800032768是我试出来的一个比较稳的值够大循环次数少又足够小不会触发参数上限。用subarray而不是slice是因为前者是视图不复制底层缓冲区处理几十MB的数据时内存占用差别很明显。3.4 一张对照表把各种输入输出对齐写代码时容易绕晕我干脆整理成表遇到不确定就查一眼起点终点推荐做法File/Blobdata URLFileReader.readAsDataURLFile/BlobArrayBufferawait blob.arrayBuffer()ArrayBufferbase64uint8ArrayToBase64(new Uint8Array(buf))base64Uint8ArrayatobcharCodeAt循环base64Blob先转Uint8Array再new Blob([...], {type})BlobobjectURLURL.createObjectURL(blob)用完记得回收canvasbase64 / BlobtoDataURL/toBlob后者更省内存Node里的Bufferbase64buf.toString(base64)/Buffer.from(s, base64)这张表建议直接贴在项目wiki里。跨端场景尤其要小心浏览器和Node的API完全不通用btoa在Node里虽然存在较新版本但FileReader没有Buffer在浏览器里也没有。同一套转换逻辑要在两端跑最好抽一个适配层而不是到处if (typeof window ! undefined)。4. 大图、批量图的性能账33%膨胀从哪来又该怎么把它按下去前面反复提到base64比原图大约三分之一这个数不是拍脑袋来的它直接决定了你的接口能不能扛住用户随手拍的手机照片。搞清楚这笔账才知道该在哪个环节动手。4.1 从24位到6位三分之一膨胀的数学来源原图是纯字节每个字节8位3个字节可以表示24位信息。base64把这24位重新切成4组6位每组用1个ASCII字符表示也就是4个字节。于是编码前后是3字节变4字节比例4/3也就是多出33.3%。再加上data URL前缀本身也有几十个字符实际膨胀比这个略高一点。算个具体的一张300万像素的JPEG压缩后大概2.5MB转成base64就是约3.4MB的字符串。如果这是从手机相册直接取的原图5MB很常见编码后接近7MB。这个字符串要经过JS字符串占内存UTF-16理论上是每个字符2字节也就是实际内存占用可能是字节数的两倍、JSON序列化再复制一份、HTTP请求体再复制一份。整个过程峰值内存可能是原图的8到10倍移动端浏览器很容易在这个环节被系统干掉。所以有一条我遵守了很久的规则超过1MB的图片不走base64通道。要么压缩到1MB以内再编码要么直接用FormData传Blob。这条规则的依据就是上面这笔内存账。4.2 主线程卡顿的定位方法以及OffscreenCanvas的用法FileReader读文件和toDataURL编码都是耗时操作在低端机上处理一张5MB图片能让页面白屏一两秒。定位方法很简单在控制台Performance面板录一段看有没有大块的长任务Long Task或者粗暴一点在转换前后打时间戳。console.time(encode); const dataUrl await fileToCompressedBase64(file); console.timeEnd(encode); // encode: 840.3ms我实测的参考数据中端安卓机4000×3000 JPEGreadAsDataURL大约120mscreateImageBitmap解码大约200ms缩放到1600px后toDataURL大约150ms三件事加起来接近500ms已经能被用户感知为点了没反应。如果缩放到800px总耗时能压到200ms左右观感上就顺多了。真要追求不卡界面把解码和编码挪到Worker里用OffscreenCanvas// worker.js self.onmessage async (e) { const { bitmap, width, height, quality } e.data; const canvas new OffscreenCanvas(width, height); const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0, width, height); const blob await canvas.convertToBlob({ type: image/jpeg, quality }); const buf await blob.arrayBuffer(); self.postMessage({ buffer: buf, type: blob.type }, [buf]); // 转移所有权 };OffscreenCanvas主线程和Worker都能用配合postMessage的转移列表上面的[buf]大块内存直接在两个线程之间移交不做拷贝。这套方案代码量比主线程版本多一些但对上传10张手机照片这类需求体验差距是肉眼可见的。4.3 容易被忽略的内存回收data URL和objectURL都是活的base64字符串一旦生成就常驻内存直到没人引用它。常见的内存泄漏是把它塞进一个大数组里忘记清空或者挂在DOM节点上不删。处理完就该让它随作用域消失别为了以后可能要用而缓存。URL.createObjectURL更需要注意因为它创建的是跟文档生命周期绑定的引用不显式revokeObjectURL就一直占着那份Blobconst url URL.createObjectURL(blob); img.src url; img.onload () URL.revokeObjectURL(url); // 图片解码完就回收我做过一个对比上传20张图片的页面不回收objectURL连续操作十轮之后内存涨到400MB以上并触发页面重载加上回收之后稳定在80MB左右。这个改动只加了一行代码收益率高得离谱。5. 一条能直接抄的完整链路粘贴、拖拽图片到压缩预览再到上传前面各节都是零件这里把它们拼成一条完整流水线。这个链路我在好几个后台系统里用过覆盖了用户从任何入口丢进来一张图片的场景。5.1 三个入口统一收敛成一个待处理文件列表用户给图片的方式有三种点选、拖拽、粘贴比如微信截图后直接CtrlV。三种来源拿到的都是File但取法不同// 1. 点选 / 拖拽 input.addEventListener(change, e handleFiles(e.target.files)); dropZone.addEventListener(drop, e { e.preventDefault(); handleFiles(e.dataTransfer.files); // 注意先 preventDefault }); // 2. 粘贴 document.addEventListener(paste, e { const files [...e.clipboardData.items] .filter(it it.kind file it.type.startsWith(image/)) .map(it it.getAsFile()) .filter(Boolean); if (files.length) handleFiles(files); });三个入口值得说的坑拖拽必须preventDefault否则浏览器会直接打开图片文件粘贴事件里items的getAsFile()可能返回null要过滤dataTransfer.files和input.files都是类数组先转成真数组再处理不然后面map、filter都用不了。收敛之后handleFiles只面对一个统一的File[]后续逻辑只写一遍。这种入口归一的习惯能省掉大量重复的条件判断也是我在图片处理里最推荐的一条工程习惯。5.2 压缩参数的取舍尺寸、质量、格式三选二压缩的三个旋钮互相牵制我的经验取值是这样的参数保守取值激进取值说明最长边19201080超过1920对普通展示没意义JPEG质量0.850.7低于0.7开始出现明显块状噪点输出格式有透明通道用PNG/WebP其余用JPEGWebP同质量下通常更小有个反直觉的结论质量从0.9降到0.75体积往往减半肉眼几乎看不出来但从0.75降到0.6体积只再减两成画质却肉眼可见地糊。所以我一般锁在0.8附近靠缩尺寸来控体积而不是一味压质量。透明通道的处理是另一个高频翻车点。用户上传一张带透明背景的PNG logo你统一转JPEG背景直接变黑。判断方法很直接file.type image/png时先考虑保留PNG或者输出WebP——WebP同时支持有损和透明代价是部分老环境不支持。真拿不准就双格式探测代价是代码复杂一点。5.3 提交阶段传Blob还是传base64按后端接口定链路最后的提交环节我默认走FormData Blob理由是体积小、内存占用低、后端拿到的就是标准文件流async function upload(file) { const blob await compress(file); // 返回 Blob const fd new FormData(); fd.append(file, blob, file.name || paste.jpg); // 第三个参数是文件名 return fetch(/api/upload, { method: POST, body: fd }); }FormData.append的第三个参数容易被漏掉不传的话后端拿到的文件名可能是个blob落到磁盘上没扩展名静态服务直接按application/octet-stream返回前端渲染又出问题。传了文件名链路上所有环节的推断都正常。只有当接口强制要求JSON字段时才退回base64方案。这时候记得三件事去掉data URL前缀或者明确说明带前缀、控制体积、给字段留足上限。我在一个项目里吃过亏——网关对单个请求体限制2MB而图片编码后经常3MB出头最后是前端先压缩到1.2MB再编码才稳定下来。6. 六个真实踩坑记录附排查思路这些坑我基本都亲自踩过写下来是希望你能少走弯路。每一个都附上当时的排查路径因为发现问题的方法比问题本身更值得记。6.1 前缀混进了内容里导致后端存的是看起来像base64的垃圾现象前端预览正常后端存库之后把字符串拼回data:image/jpeg;base64,渲染图片是破图。排查把库里存的字符串开头打印出来发现是data:image/jpeg;base64,data:image/jpeg;base64,/9j/...前缀套了两层。根因前端readAsDataURL返回带前缀前端没剥离就提交展示时又拼了一次。修复很简单定一个约定接口传输的字符串永远不带前缀前缀由展示层负责拼。约定定好之后全链路只在一个地方拼前缀。6.2 MIME类型丢失去导致文件变成.bin现象上传的PNG在后端存成了xxx.bin浏览器下载下来打不开。排查base64ToBlob默认参数写的是image/jpeg所有图片都被标成了JPEG。而PNG的字节内容配JPEG的MIME某些服务端会做校验并拒绝或者按MIME写扩展名。修法有两个方向一是从原文件带过来file.type二是做魔数嗅探——读前几个字节FFD8FF是JPEG89504E47是PNG47494638是GIF。我在一个只收base64字符串没有原始file对象的接口里用过魔数嗅探十几行代码比让后端猜可靠得多。6.3 iOS照片转了90度EXIF方向信息在转换中丢了现象iPhone竖拍的照片上传预览后变成横的安卓机正常。根因手机拍照时传感器方向和实际显示方向不一致方向信息记在EXIF里。canvas.drawImage绘制的是解码后的像素不带EXIF方向JPEG编码输出也不再写方向标签于是摆正这个动作丢失了。修法用createImageBitmap(file, { imageOrientation: from-image })让浏览器在解码阶段就把方向应用上或者手动读EXIF的Orientation标签根据值做旋转。前者一行代码但浏览器支持情况得自己确认我的做法是加个能力探测不支持时退回手动处理。6.4 跨域图片画到canvas后toDataURL直接抛SecurityError现象业务需要给CDN上的图片加水印img.src设好、crossOrigin也设了drawImage没问题一调toDataURL就报错。排查控制台报Failed to execute toDataURL: Tainted canvases may not be exported也就是canvas被污染了。根因跨域图片一旦绘制到canvas这张canvas就被标记为不可导出除非图片是带CORS头加载的。设img.crossOrigin anonymous只是前端的一半服务端必须返回允许跨域的响应头两边缺一不可。顺带一个顺序问题crossOrigin必须在设置src之前赋值反了就不生效。这个顺序错误我见得太多了。6.5 大字符串塞进JSON请求体爆掉现象接口偶尔返回413图片大一点必现。排查抓请求看Content-Length发现base64字段占了绝大部分。前面算过base64是原图的1.33倍再加上JSON转义某些字符会被转义和字段名能到1.5倍。修法分三层前端压缩控制到1MB以内调整字段为可选的分片提交把大图切成多段依次上传接口层放宽限制。三层里面前端压缩收益最大、改动最小所以先做它。6.6 浏览器和Node的API不通用同一段逻辑两端跑不起来现象图片处理逻辑抽成了公共模块浏览器里跑得好好的放到服务端渲染环境里直接报FileReader is not defined。排查FileReader、Image、canvas、btoa部分老版本Node没有都是浏览器环境专有反过来Buffer、fs在浏览器里没有。修法把转换函数按能力拆开环境相关的部分做适配层公共部分只处理Uint8Array。字节数组是唯一可移植的中间格式这句话是那次重构的最大收获。两端各写一个薄薄的外壳把输入输出都归一到Uint8Array核心逻辑就真的只有一份了。我个人在实际操作中的体会是图片转换这件事的难点从来不在API本身而在你有没有在动手之前把数据形态、传输通道、体积预算这三件事想清楚。想清楚了代码可能只有三十行没想清楚写三百行也还是会在大图、跨域、老机型上翻车。最后分享一个我一直在用的小技巧在项目里准备一个toBase64/fromBase64的小工具文件所有形态转换只走这一个出口出问题时只需要看这一个文件。这个文件我写了一版又一版现在稳定在两百行左右却替我挡掉了至少十次线上事故。