图片Base64进参数后打不开，先查加号有没有变成空格

Base64 在本地可以解码，放进 URL 参数后却失败，不一定是图片内容坏了。字符串经过参数拼接和解析时，也可能被改变。一个值得先查的字符是加号 +。

用最小例子看变化发生在哪一层

以下是本地可复算的一字节演示，不是一张可打开的 PNG，也不是某个接口的真实故障记录：

const encoded = '+w==';
const bad = new URLSearchParams('image=' + encoded).get('image');
console.log(JSON.stringify(bad)); // " w=="

const params = new URLSearchParams();
params.set('image', encoded);
console.log(params.toString()); // image=%2Bw%3D%3D
console.log(params.get('image')); // +w==

第一种写法把数据直接拼进待解析的参数字符串。在这条表单式解析路径里，加号会变成空格。第二种把原值交给参数对象编码，加号被表示为 %2B，再次读取仍是原值。

这个例子证明的是字符串在参数层改变了，不证明任何图片已经完成格式解码。不要把一字节演示冒充成“成功还原图片”的测试。

解码器忽略空白，也可能救不回来

图叮当前图片 Base64 解码会移除空白，再检查字符、长度、解码结果和文件头。如果原来承载信息的 + 已经变成空格，移除空格等于继续丢掉那个字符，并不会知道原来应该补哪一个值。

所以不要把“支持换行的 Base64”误解成“任何加号变空格都能恢复”。也不要在不了解传输链的情况下，把所有空格无条件替换成加号；那可能掩盖截断、错误拼接或别的输入问题。应从原始可靠值重新按正确方式发送。

分段保存，找到第一次变动

排查时可以保留三份脱敏测试值：编码后、构造参数后、接收端解析后。对真实业务图片，优先在受控本地环境比较长度和哈希，不把完整图片数据塞进公开日志。

先确认接收端采用什么承载方式：JSON、表单和 URL 参数不是同一个格式。不要为了“保险”重复编码整个字符串，也不要把已经编码的 %2B 再交给同一层编码却期待得到原来的请求形式。

如果需要规范构造参数，就让对应参数 API 处理值，而不是手工拼接 image= 加原始 Base64。具体接口仍要按接收方合同执行，本文的 JavaScript例子不替代接口文档。

传输没变，再检查图片本身

字符串往返一致之后，还要检查 MIME 和实际文件头是否相符、能否完整还原、尺寸是否正确。当前图叮工具会拒绝声明 MIME 与识别出的图片类型不一致的输入；能进行 Base64 解码，不等于得到了一张支持的图片。

可以用图叮图片 Base64 工具核对原始可靠数据，再按复制完整性与回图核验方法检查最终结果。先解决参数层的改变，再处理图片层问题，不要反复压缩同一张图来修传输编码。