文件上传FormData再次上传文件选框很长时间才弹出
前端用axios上传到后端，上传一次zip文件后再次打开文件选择弹框需要很久，期间浏览器卡死（似乎被未弹出的弹框占用了zindex?），发现和文件大小关系不大，上传300M的文件甚至比1M的都快，相反，我发现只要zip里的文件夹目录数量很多，每个目录还有其他文件，这种情况就会出现卡死的情况，做了下实验，zip文件里的目录数量确实会影响再次打开弹框的速度，越多越慢，而且令我比较好奇的是1、前端XHR.send()结束后才进到后端的断点里
2、文件层级结构为什么会影响速度，传输都是按二进制传输，难道还要遍历结构？
有没有坛友明白这里面的原理？比如在进入后端断点前前端对这些数据在进行什么处理，出现卡死的情况请求时间竟然大部分都是1Min(axios超时设置的0)
另：
查到有很多离谱的解释，有说和搜狗输入法有关，和浏览器GPU加速有关，和Chrome版本有关（bug不成？这么基础的组件不支持这么常见的场景？） 建议开个虚拟机在纯净环境下测试对比下 你的后端是怎么接收的?分块接收?还是整体接收完后再返回消息,有没有可能是你服务端对这个文件进行查杀占用资源了? 错的是世界 发表于 2024-9-18 20:20
你的后端是怎么接收的?分块接收?还是整体接收完后再返回消息,有没有可能是你服务端对这个文件进行查杀占用 ...
后端是node multer接收，没有分块、断点续传 我在文心上问的回复,感觉比较合理,你可以根据此来完善你的代码: 在HTTP请求中，XHR.send() 方法用于将请求发送到服务器。在这个调用之后，浏览器会将请求发送到网络，并且这个调用是异步的。这意味着 XHR.send() 方法会立即返回，而实际的请求/响应过程在网络上进行，不会阻塞JavaScript的执行。因此，你的JavaScript代码会继续执行，直到收到服务器的响应（通过XHR的回调或事件处理器）。
当你说“XHR.send()结束后才进到后端的断点里”，这实际上指的是请求数据完全发送到服务器并且服务器开始处理请求的时间点。在服务器接收到完整的请求体之前，服务器端的断点可能不会被触发，尤其是当文件较大或网络较慢时。2. 文件层级结构为什么会影响速度
虽然文件传输本身是二进制的，但浏览器在准备文件上传时可能需要遍历文件系统的结构，特别是当你选择的是包含大量文件和子目录的ZIP文件时。这个过程可能包括：
文件扫描：浏览器需要扫描ZIP文件以获取其内容列表，这包括文件名、文件大小和可能的元数据。如果ZIP文件包含大量文件或深层目录结构，这个过程可能会相对较慢。
UI更新：在文件选择后，浏览器可能需要更新UI以显示文件信息，这可能会进一步增加响应时间。
内存使用：处理大型或复杂的ZIP文件可能会消耗更多的内存，这可能会影响浏览器的整体性能。
3. 解决方案或缓解措施
优化ZIP文件：尽量减少ZIP文件中的文件和目录数量，特别是那些不必要的或可以合并的文件。
使用Web Workers：如果可能，可以使用Web Workers来处理文件选择和处理过程，以避免阻塞UI线程。
增加超时时间：如果上传过程确实需要较长时间，考虑增加axios的超时时间设置。
浏览器性能优化：确保浏览器和操作系统是最新的，以利用最新的性能改进。
调试和性能分析：使用浏览器的开发者工具来分析和优化前端性能，特别是关注网络请求和内存使用情况。 你这问题我碰到过，似乎是和浏览器的版本有关系，特别是谷歌，有时候这个弹出框能卡个30多秒，具体来说也不能说是浏览器的问题，反正是win的文件管理器这一块的问题，重做了系统就好了 用原生js试吧，用了前端框架，有可能是框架为了加速，事前对zip这类可解压的文件做过分析
或者把zip文件加密码试传。 bigcan 发表于 2024-9-19 08:22
用原生js试吧，用了前端框架，有可能是框架为了加速，事前对zip这类可解压的文件做过分析
或者把zip文件 ...
原生没有问题，好像确实是只要是vue就有这个问题，这个分析是官方有声明吗，在哪能找到证据？
页:
[1]