前端保存数据到后台时请求数据太大该怎么处理？

个人的不成熟想法：
1，把”修改“传给后端，比如删掉了从 index1 到 index2 之间的内容，在 index1 后面添加了什么内容这样子
2，后端把修改重现到数据库中的数据上
于是新的问题来了
1，巨大的数据频繁往返于数据库和应用，对内存和网络都是不小的压力，于是要考虑做应用级的缓存，应用级的缓存是本地的不是分布式的…不想了
2，还要处理修改本号，数据版本号之类的问题，防止数据乱掉…不想了

@chendy #1 这个方案我也想过因为太麻烦，而且变化量的块太多了则需要一些方案来保证数据的一致性。太费劲了。

一般这种大小限制都是框架限制的吧, 那就直接修改框架选项调大一点就好了吧, 但是总归是要限制一个大小的

建议不要因为一个配置问题而去修改逻辑。

你把数据库改了，万一其他业务以后需要这一部分数据咋办

既然服务端做了限制为什么客户端可以传这么大既然客户端传这么大为什么服务端做了限制，既然你一定要传这么大为什么不去修改服务端限制跑去修改逻辑

这种还是服务端改限制好，分片得改代码。。麻烦

文本输入框也不至于输入超过限制的文本大小吧.. 那得写多少东西 ... 是不是有图片类的文件被转成了 base64 导致文本大小变大 如果过是 应该考虑图片或者文件改成链接

分 trunk 上传啊，有 fileupload 组件支持前端分 trunk 得

当技术实现不了的时候：这个需求有问题

？？？ 诛仙正本小说才 1.5M

互相矛盾，建议修改服务端限制，node 本身有啥限制，你说的是 http 的 body 体积吧，这个都是可以配置的。

需求不知道，方案设计肯定有问题，这种 MB 级的文本应该搞成文件上传

1，大文件分片上传没错。但存储分片更多的带来麻烦不会带来多少收益。一般不分片存储。比如跨分片搜索、匹配、解码、修改等各种操作。
2，如果非要分片存储，可以把每个分片做 hash。无论初次还是后续上传，按分片做 hash 来判断是否可以“秒传”。然后传输那些 hash 无法匹配的分片即可。
3，新的分片们到达服务器，依然按 hash/id 做存储。文件元数据本身会保存拥有的所有分片的索引。
4，每个分片有引用计数，定期删除没有引用的分片。

以上都是脑洞。
我们的做法是直传阿里云等各种云存储，自带 SDK 支持秒传、分片等信息。云存储后给业务层传个最终结果 key 就可以了。这样存储子系统和业务子系统可以独立，业务子系统不用修改巨大的 body 体积上限，也不用占用巨大的带宽和连接时长。

你直接把限制放大不就行了... 真有这个需求，为什么不放开限制呢，而且你究竟是传了多大的文字...

文字转 blob，分片上传

你这是有多大啊 上传视频吗

@flyingghost #14 正解，前端直传，云存储提供商 callback 后端。