- Shipped
- 2026年8月11日 16:21 UTC
- Author
- kamo
- Commit
- f1de4ec
后端现在流到 3 GiB, 但浏览器和 BFF 中的三件事 无法到达,每个致命的自己。 上传代理机确实“ 等待请求. formData () ” , 将文件拉出, 重建了第二个 FormData to forward——这个过程中的整个上传都是堆积,两次. 现在它管住尸体 直接通过节点: http, 聊天附图代理已经使用的同一构造 在生产中携带3个GiB. 节点:http 而不是取出, 因为 Undici 应用了 300s 信头 每个请求都超时,多吉加比特的上传比线上要长得多 在“转换服务”——在回答前将拼接的文件排出——之前,可以回复;与 获取, 代理而不是产品会决定最大文件大小 。 计算Blake3(文件)和计算Sha3256(文件)每个调用文件.arrayBuffer(),以及上传器 让他们在承诺中运行。 所有,所以文件是完全 居住于标签TWICE 在高峰。 在老的时候 已经是千兆字节的500MB 标签内存; 在 3 GiB 时, 它为 6 个, 标签在 3 个 3 个 6 个 之前就死了 。 a 字节已上传。 替换为 computeFileDigests, 它将文件在 4 MiB 切片中行走一次 并且从同一块中喂入两个散列器——峰值内存是任意大小的一个块,镜像 HashUtils.compute Digests 在服务器上. 由于上传,两本文摘仍在计算 端点重算并比较两者; js-sha3 纯为 JavaScript 并主导时间, 这 是更强大的服务器边检查的价格,所以散列现在报告进展而不是 以2%的速度坐几分钟 MultiFileUploader完全没有尺寸限制,所以一个超大小的选手花上几分钟的花销来挣取一个 不透明失败。 在读取文件之前检查大小, 文件会在 错误阶段同时命名其大小和限制 .