如果文件直接用 base64 编码传，会怎么样

[frank1256]

修改一个上传文件的接口给同事，本能的就使用 form-data 。 原本是没有上传文件的需求，content-type 是 json ，现在我改成 form ，分 2 个 key ，一个是 attachments ，一个是 req ，req 是原来 json 的字符串。

同事说直接让我还用 json ，并且在它直接将文件转 base64. 跟图片一样的意思。

他说附件不大，我觉得这样有隐患，该怎么说呢，我认为我毕竟是接口，万一给我传个 500M 的字符串啥的，这 500M 我不就全部要吃到内存里。而通过 multiple/form-data 的话，应该是从 io 流里读的，不会一次性吃 500M 内存。

问下大佬们是这样的吗？

[binux]

你又不是后端，他爆内存和你有什么关系？
如果和你有关系，你帮他改成 form 不就完了。
如果和你没有关系，你凭什么指手画脚？

[dangyuluo]

你想一下，原本一个字节可以表示 0-255 这 256 种不同的数据，用 base64 编码之后，一个字节就只能有 65 种可能了，纯属是浪费时间空间

[hb751968840]

上传就是 form-data ，或者 PUT ，其他都是乱搞

[zilongzixue]

这不是扯淡吗，改成 form-data 又不难，一个注解就完事了

[echo1937]

当然可以啊，以前有个 Markdown 的编辑器，你粘贴图片的时候，他就是把图片转码成 Base64 附在 Markdown 文件的末尾。

[lcy630409]

一般有一个专门上传文件的接口和函数，原 json 参数传文件名即可，接口内 代码使用文件函数 转移文件到最终存放地，临时文件夹 定期清空

[lakehylia]

文件太大还是改接口吧，搞个 v2 接口

[Songxwn]

企业微信的微盘就是，第三方只能用 base64 上传

[DinnyXu]

现在不都是用 url 后台解析吗？ 前台将文件上传到 OSS 获得 url ，传输给后台一个 url ，后台自己解析 url 内容不就可以了吗，这不更快？

[nothingistrue]

如果单看编程，base64 编码进 json 里面，省事的不光前端，也有后端，而且后端省事的更多。这个的问题是，随着文件的增大，接口的处理时间、服务器的并发能能力、网关、日志等多处地方的性能都会收到影响，而且通常影响程度至少是指数级。这东西是要在编程省事和性能优化之间做权衡的，做这个权衡的，应该是架构师或者有过经验的人，不是是当事开发前后端双方。

[seth19960929]

好的做法就是你前端直传文件就可以, 然后把文件 URL 和你 req 提交给后端

[unco020511]

你们没有业务无关的存储服务吗,业务接口一般都不关注文件存储的,只关心 url

[MineDog]

@dangyuluo #22 是这么算的？

[dangyuluo]

@MineDog 如果是错误的话，请教正确的计算

[MineDog]

@dangyuluo #34 我的问题，确实是浪费了 2bit 的空间

[MineDog]

@dangyuluo #34 不过计算方式是原本 3*8=24bit 的数据需要 4*6(base64 字符，只表示 6bit 但实际还是占用还是 8bit ）表示，相当于浪费了 2bit 的空间