文件夹上传卡顿主因是change事件中同步遍历files触发浏览器批量初始化，而非webkitdirectory本身慢；应限流处理、避免同步I/O、禁用实时DOM插入、分片并发控制。
文件夹上传卡顿，根本不是 webkitdirectory 本身慢，而是你一拿到 e.target.files 就立刻遍历、读取、渲染或触发元数据解析，浏览器被迫为每个文件同步生成缩略图、扫描路径、甚至预加载——尤其在选中含 50+ 个 CAD 或 STEP 文件的机械设计包时，UI 直接假死。
别在 change 事件里直接遍历 files.length
Chrome/Edge 在用户点选文件夹后，会立即为所有子文件初始化 File 对象（含 webkitRelativePath），但某些 WebView（如 Electron 或旧版 iOS）会在你访问 files[i].size 前就偷偷做 I/O。看似只读属性，实则已触发沙盒内同步扫描。
- 用
Array.from(e.target.files).slice(0, 20)主动限流，跳过多余文件，避免批量初始化 - 过滤掉 macOS 隐藏目录：
file.webkitRelativePath.includes('__MACOSX') || file.name.startsWith('.') - 不要在循环里调
file.arrayBuffer()、file.text()，哪怕只是想“验证下是不是 PDF”——这会立刻卡住主线程 - 若需快速校验类型，只比对
file.type（如'application/pdf'）或后缀file.name.split('.').pop().toLowerCase()
构建文件树时禁用实时 DOM 插入
机械制造场景常需展示完整目录结构，但逐个 document.createElement('div') 并 appendChild 会触发多次重排，100 个文件就能让 60fps 掉到 10fps。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
document.createDocumentFragment()批量构建节点，最后一次性挂载 - 路径分割用
file.webkitRelativePath.split('/')即可，别用正则或URL构造器处理路径字符串 - 长路径显示要截断：
path.length > 50 ? '...' + path.slice(-47) : path，避免文本强制换行撑宽容器 - 统计信息（如总文件数、总大小）单独计算，别塞进渲染循环里
大文件夹上传前必须做分片与并发控制
一个含 200 个 DWG 文件的 BOM 包，总大小可能超 8GB。不控制并发，前端会同时发起上百个 fetch 请求，内存暴涨、TCP 连接打满、服务端拒绝响应。
立即学习“前端免费学习笔记（深入）”；
- 上传队列用 Promise 链或
async/await串行化，或限制并发数（如最多 3 个fetch同时进行） - 单个大文件（>50MB）必须分片：
file.slice(start, end)，chunkSize 设为4 * 1024 * 1024（4MB），不复制内存 - 每片上传后才切下一片，避免
FileReader或fetch堆积未完成任务 - 监听
xhr.upload.onprogress或fetch的ReadableStreamreader，但注意 Safari 不支持后者进度事件，需 fallback 到定时估算
最易被忽略的一点：文件夹上传的“卡”，往往发生在用户还没点上传按钮之前——是浏览器在后台默默初始化造成的。真正的优化不在上传逻辑里，而在你第一次碰 e.target.files 的那一刻是否克制。宁可少显示两个文件，也不能让 UI 假死三秒。
