drop事件中需用dataTransfer.items而非files才能获取文件夹，通过webkitGetAsEntry识别目录并递归读取，注意分批处理、让出执行权、限制深度及移动端降级。
drop 事件里拿不到文件夹里的文件？检查是否用了 dataTransfer.items
拖拽文件夹时，dataTransfer.files 通常为空或只含占位项——浏览器不把整个文件夹当“文件”塞进去，而是通过 dataTransfer.items 暴露为 DataTransferItem 列表，其中可能包含 kind === 'file' 或 kind === 'directory' 的条目。必须用 items 才能识别并递归读取文件夹内容。
常见错误是直接遍历 event.dataTransfer.files，结果文件夹拖进来却没反应。正确做法是：
- 先遍历
event.dataTransfer.items - 对每个
item调用item.webkitGetAsEntry()（目前仍是事实标准，Chrome/Safari/Firefox 均支持） - 判断返回的 entry 是
isFile还是isDirectory，再分别处理 - 目录需调用
createReader().readEntries()递归展开，注意异步和栈深限制
为什么 webkitGetAsEntry 在某些浏览器报错或返回 null？
webkitGetAsEntry 不是标准 API，但已被主流浏览器长期支持；它失效通常不是因为被移除，而是触发条件未满足：
- 用户必须拖拽的是**真实文件系统目录**（如 macOS Finder / Windows 文件资源管理器中的文件夹），不能是 zip 解压后的虚拟目录或桌面快捷方式
- 事件必须来自
drop，且dragover中已调用preventDefault()—— 否则整个拖拽流程被浏览器拦截，items可能被清空 - 部分浏览器（如旧版 Firefox）对文件夹拖拽支持不稳定，建议降级 fallback：检测到无有效 entry 时，提示“请改用点击上传或拖入单个文件”
- 不要在
dragenter或dragover阶段调用webkitGetAsEntry，它只在drop后有效
递归读取文件夹时如何避免卡死或爆栈？
文件夹嵌套过深、单次读取条目过多，容易阻塞主线程甚至触发浏览器终止脚本。不能直接写 while (entries.length) 同步递归。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 用
async/await+for await...of配合DirectoryReader（如果环境支持），否则用readEntries分批拉取（每次最多 100 条） - 每层递归后加
await new Promise(r => setTimeout(r, 0))让出 JS 执行权，防冻结 - 设置最大递归深度（如 8 层），超限时跳过子目录并记录警告
- 大文件（>100MB）不预读内容，只收集路径和元信息；上传阶段再分片读取
- 用
AbortController控制整体读取流程，方便用户中止
移动端和 Safari iOS 能否拖拽上传文件夹？
不能。iOS Safari（包括 16.4+）和所有 Android 浏览器均**不支持拖拽文件夹**，dataTransfer.items 为空，webkitGetAsEntry 返回 null。这是平台级限制，不是代码问题。
必须做明确降级：
- UA 检测到移动设备或
navigator.userAgent.includes('iPhone') || navigator.userAgent.includes('Android')，直接隐藏拖拽区，只显示<input type="file" webkitdirectory directory multiple> - 该
input在 iOS 上会唤起文件选择器（支持文件夹选择，但仅限 iCloud 和“文件”App 中的目录） - 注意：
webkitdirectory在非 Chrome 内核桌面浏览器中兼容性差，仅作为移动端 fallback，不要在桌面端依赖它
