如何让浏览器支持上传超大文件夹？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2549 天前的主题，其中的信息可能已经有所发展或是发生改变。

如果上传超过 150 多万个文件的文件夹（视你的机器配置，我的配置是 16G 内存）浏览器就会 crash （原因是浏览器会全量读取 file stat list) https://codepen.io/ahuigo/pen/WWPeLP

排除方案：

将文件夹打包再上传：按照我们的场景，每次打包 1TB 硬盘是不现实的时间长（打包、解包）、还需要备用一块硬盘, 运营是不愿意手工打包的
采用非 web upload 方案, 本地客户端没有 FileAPI 限制（开发成本大）

替代方案：

开发命令行版的上传方案，没有 UI 交互，非常不人性化

https://bugs.chromium.org/p/chromium/issues/detail?id=958679

打包

上传

文件

浏览器

17 条回复 2019-11-25 17:42:42 +08:00

jwk345

2019 年 5 月 2 日 via iPhone

这种场景不适合 web，开发一个本地客户端能有多大成本？

JmmBite

2019 年 5 月 2 日

测试了一下，四十万的数量就 Crash 了，还是写个客户端吧，逻辑差不多，加一个目录扫描功能。

azh7138m

2019 年 5 月 2 日 via Android

这是一个 XY 问题

如果是同步场景建议 rsync。
如果是办公数据备份，请使用专业存储，本地 nfs 挂载。

airyland

2019 年 5 月 2 日 via iPhone

不一定要命令行，用 electron 写 ui 来指定上传目录，node 来遍历异步执行。

a132811

2019 年 5 月 2 日

@azh7138m 3ks, 我们的场景比较特殊，不可以直接用 rsync 同步。
我们的存储是通过 s3 或者 oss 协议传到阿里、AWS、自建存储，在这个基础上要有上传前后对包文件夹（符合特定名字的文件夹就是包）的监控：上传前预处理+后处理、权限方面控制、相关任务流逻辑、每个包进度监控

@airyland @jamesxu
现在已经开发的 web 版主要就遇到这一个问题，能解决此问题话就尽量不搞客户端（适匹多端、客户端更新也是浪费精力）

JamesR

2019 年 5 月 2 日

“尽量不搞客户端（适匹多端、客户端更新也是浪费精力）”，搞笑。

a132811

2019 年 5 月 2 日

@JamesR 这个只是我们大量需求的一个，我们组不是专门搞客户端的。哪里搞笑了？

xiaogui

2019 年 5 月 2 日

这种场景不适合 web +1

JamesR

2019 年 5 月 2 日

@a132811 #7 浏览器原本就不是用来干这个的，百度网盘为什么要做个客户端呢，你有没有想过？它为啥不弄纯 Web 浏览器上传下载呢？

又要马儿跑（浏览器不用安装客户端），又要马儿不吃草（浏览器啥都能干）那是不可能的。

要么自己老老实实手动慢慢传文件，要么就自学开发个程序全自动帮你传。

azh7138m

2019 年 5 月 2 日 via Android

@JamesR 百度的问题和楼主不一样，大量的网盘可以直接使用
比如 mega onedrive googledrive，强制客户端只是百度的运营策略。

那建议 https://electronjs.org 包一下吧，成本低。这么复杂的需求为啥不搞个端。。。

a132811

2019 年 5 月 2 日

@JamesR 很多事过去是不可能，以后未必不可能。浏览器的边界一直在延伸，PWA/service-worker、webRTC 在过去很多人都没有想过。
---------------------
话题又扯远了。目前这个问题在官方支持前应该是无解。只能客户端和命令行了。我比较偏向于 flutter

JamesR

2019 年 5 月 2 日

@a132811 #11 请问能纯浏览器实现自动化批量（包括选择打印机，纸张等）打印吗？
它为啥不能呢？还有它为啥不设计能读取修改本地用户文件呢？
等等等等，这和浏览器原本的的设计用途有关。

ipwx

2019 年 5 月 2 日

@a132811 恰恰相反，曾经用 IE + ActiveX 一定能实现楼主的需求。Java Applet 也能实现。Flash 的话，似乎好像也能实现？

但是我们大家都看到了，这些技术就是漏洞百出的筛子，能让黑客轻易控制用户计算机。所以现在的浏览器反而收窄了边界。

ochatokori

2019 年 5 月 2 日 via Android

浏览器确实不合适，甚至难度非常大，至少现在来说
既然你们已经开发了一定程度的 web 版，建议移植到 electron 上，把这活给下层的 node 干，这样工作量比重新开发客户端快多了还能解决问题

a132811

2019 年 5 月 2 日

@JamesR 你是不是想告诉我浏览器的所涉及的安全问题？我当然明白这个涉及到用户授权的问题，我讨论的范围也是用户要点击 button 选择文件夹后，“授权”后才能做的事情（现在 chrome 不就支持这么做么）。我没有说自动读取用户的文件系统呀。

activeX/applet/flash 之类的已经不属于浏览器的自身了。只能说明过去浏览器功能支持太有限。

@ochatokori 谢谢你的意见 electron 或许是一个不错的选择

Tomorr

2019 年 5 月 3 日

WebAssembly wasm 不知道这个玩意有不有得搞，（谷歌的图片压缩 squoosh 等等）

a132811

2019 年 11 月 25 日

wasm 不是解决这种 api 问题的。wasm 未来用来写 cpu 密集的逻辑。

5 个月后，chrome 出了 native file api，可以说彻底解决了访问本地文件、文件夹的问题：
https://web.dev/native-file-system/