Base64 图片不显示？10 个高频原因与修复清单

图片已经转成 Base64，data URI 也塞进了 HTML——然后，什么都没显示。只看到一个裂图标。更离谱的是：Chrome 能显示，Safari 不行；本地能跑，部署就挂。

Base64 图片显示失败之所以令人抓狂，是因为字符串看起来完全正常。真正的原因往往藏在细节里：前缀少了一个字符、复制粘贴时混入了不可见的空白、或者后端偷偷做了二次编码。本文覆盖全部 10 种常见原因，每种都附带代码示例和修复方法。

速查表：症状 → 原因 → 修复

先从这里开始。找到你的症状，定位可能的原因，再跳到下方看详细修复。

前缀出错：data: URI 写法有误

data URI 的语法要求非常严格。错一个字符，浏览器就会把你的 Base64 字符串当作一个坏掉的 URL，而不是图片数据。

原因 1：整段 data URI 前缀缺失

如果直接把裸的 Base64 字符串赋给 src，没有加 data:image/...;base64, 前缀，浏览器会把它当成相对路径去请求——结果就是 404。

❌ <img src="iVBORw0KGgo..." />
✅ <img src="data:image/png;base64,iVBORw0KGgo..." />

原因 2：分号写成了逗号

写成 data:image/png,base64,... 而不是 data:image/png;base64,...，浏览器会把 base64,... 当作纯文本内容，而不是 Base64 编码标识。

❌ data:image/png,base64,iVBORw0KGgo...
✅ data:image/png;base64,iVBORw0KGgo...

原因 3："base64" 后面漏了逗号

base64 和实际数据之间的逗号不能省。如果写成 data:image/png;base64iVBOR...，浏览器会把 base64iVBOR... 当作字符集名称，而不是编码数据。

❌ data:image/png;base64iVBORw0KGgo...
✅ data:image/png;base64,iVBORw0KGgo...

编码损坏：Base64 字符串本身有问题

即使前缀完全正确，编码后的数据也可能在存储、传输或复制粘贴过程中被悄悄破坏。

原因 4：字符串被截断

数据库字段有长度上限（比如 VARCHAR(65535)），会静默截断 Base64 字符串。一张 100KB 的 PNG 编码后约 136,000 个字符——如果字段在 65,535 处截断，解码出来的图片直接是坏的。修复：存储 Base64 请使用 TEXT 或 LONGTEXT 类型。

原因 5：混入了非法字符（空格、特殊符号）

合法的 Base64 只包含 A-Z、a-z、0-9、+、/ 和 =。复制粘贴时混入的空格会导致 atob() 直接抛出 InvalidCharacterError。修复：使用前先去掉所有空白字符：str.replace(/\s/g, '')。

原因 6：换行符污染

openssl base64 默认每 76 个字符插入一个 \n（遵循 RFC 2045）。这些换行符在 HTML 的 data URI 里会导致解码失败。修复：使用 openssl base64 -A（单行输出），或去掉换行：str.replace(/[\r\n]/g, '')。

原因 7：Padding 被 URL 解析吃掉

Base64 末尾的 = 填充字符在通过 URL 参数传递时经常被吞掉，因为 = 在 URL 中是保留字符。有些浏览器能容忍缺失的 padding，有些不行——导致跨环境行为不一致。修复：放入 URL 前先做 encodeURIComponent()，或在接收端手动补齐 padding。

MIME 类型不匹配：真的会挂吗？

这条可能会让你意外：声明了错误的 MIME 类型，大多数情况下图片依然能正常显示。

原因 8：声明的 MIME 与真实文件类型不一致

如果你写了 data:image/png;base64,/9j/4AAQ...（JPEG 数据却声明为 PNG），大多数现代浏览器依靠内容嗅探（content sniffing）依然能正确渲染。但有两种场景确实会出问题：(1) 配置了严格 CSP 且启用了 MIME 强制校验，(2) 服务端按声明的 MIME 做格式转换，导致输出损坏。结论：修好它是正确做法，但它极少是显示失败的真正元凶。

链路问题：数据到达浏览器前就已经坏了

这类问题最难排查，因为你代码里的 Base64 字符串看起来完全正常——损坏发生在序列化或传输环节。

原因 9：双重 Base64 编码

后端对已经编码过的数据又做了一次 Base64 编码，结果变成了对 Base64 字符串再做一次 Base64。长度比预期多 ~33%，解码一次后得到的是文本而不是二进制图片数据。识别方法：解码一次，如果结果看起来还是 Base64（字母开头、= 结尾），说明被双重编码了。修复：去掉后端管线中多余的编码步骤。

原因 10：JSON 转义或 URL 编码污染

Base64 字符串包含 / 字符。某些 JSON 序列化器会把它转义为 \/。如果前端没有用 JSON.parse 正确解析，而是直接取原始字符串，多出来的反斜杠就会污染数据。类似地，通过 URL 参数传递 Base64 时，+ 会变成空格，= 会被吞掉。修复：JSON 数据务必使用 JSON.parse()。URL 传输使用 encodeURIComponent()。

系统排查模板

如果以上原因都没命中，按以下步骤逐项排查：

1. 在浏览器地址栏测试 data URI — 把完整的 data:image/...;base64,... 字符串直接粘贴到地址栏。如果能显示，说明问题出在应用注入字符串的方式上。
2. 检查浏览器控制台 — 按 F12，在 Console 标签页查找 net::ERR_INVALID_URL 或 CSP 违规等错误信息。
3. 比对字符串长度 — 对比源头（后端）和前端拿到的 Base64 字符串长度。如果不一致，说明传输过程中发生了截断或损坏。
4. 解码并检查 — 在控制台用 atob() 解码前几个字符。如果抛出 InvalidCharacterError，说明字符串中混入了非法字符。
5. 检测双重编码 — 解码一次。如果结果看起来还像 Base64 字符串，再解码一次。如果第二次解码得到了二进制数据，说明处理链路中存在多余的编码步骤。

用 ViewJSON 一键验证 Base64

与其手动检查 Base64 字符串，不如直接把 JSON 粘贴到 ViewJSON。它通过魔数检测自动识别 Base64 编码的媒体并渲染行内预览——如果预览正常出现，说明你的 Base64 是有效的；如果没有，你可以精确定位是哪个字段出了问题。