webkitdirectory仅被Chrome、Edge（Chromium内核）、Opera及Safari 16.4+原生支持；Firefox、IE/旧版Edge、Android/iOS部分环境不支持或行为不稳定，且非标准属性无法跨浏览器通用。
HTML5 webkitdirectory 属性支持哪些浏览器？
只有 Chrome、Edge（基于 Chromium）、Opera 和新版 Safari（16.4+）原生支持 webkitdirectory —— 这是目前唯一能通过单个 <input type="file" webkitdirectory> 选中整个文件夹并保留层级结构的原生方案。Firefox 完全不支持该属性，IE/旧版 Edge（EdgeHTML）也不支持。
常见错误现象：input 点击后只弹出文件选择框、无法勾选“文件夹”选项；或控制台静默忽略 webkitdirectory 属性；Vue/React 中绑定该属性但无效果——大概率是浏览器不识别。
- Safari 16.4 之前：不支持，即使加
-webkit-前缀也无效 - Firefox：从未实现，官方明确拒绝（出于安全与隐私考虑）
- Android Chrome / iOS Safari：部分支持但行为不稳定，iOS 上常被拦截或仅返回根目录文件
- 国产双核浏览器（如 360、QQ 浏览器）：仅在“极速模式”（Chromium 内核）下可用，兼容性取决于内核版本，非默认行为
想让 Firefox 或旧浏览器也支持文件夹上传？没有标准 API，只能降级
Firefox 和 IE/EdgeHTML 不提供任何原生文件夹遍历能力，webkitdirectory 在它们身上就是无效字符串。强行加属性不会报错，但也不会触发文件夹选择逻辑。
可行的降级路径只有两条：
立即学习“前端免费学习笔记（深入）”；
- 改用 WebKit 浏览器专属页面 + 明确提示：“请使用 Chrome 或 Edge 浏览器上传文件夹”
- 放弃“一键选文件夹”，改用“多文件选择 + 客户端解析路径”方案：用户手动选中所有子文件，前端用
file.webkitRelativePath提取相对路径（仅 Chromium 系列有效），再按路径重建树结构；Firefox 返回的file.name是纯文件名，无路径信息，无法还原层级
注意：webkitRelativePath 不是标准属性，Firefox 返回空字符串，IE/EdgeHTML 不支持，不能用于跨浏览器路径还原逻辑。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
服务端收到的“文件夹结构”到底靠谁保证？
浏览器只负责把文件列表和可选的相对路径传过来，webkitRelativePath 字段是否携带、是否可信、是否完整，完全取决于客户端。服务端无法从 HTTP 请求体里反推原始文件夹结构——除非前端主动把路径作为额外字段提交（如 FormData.append('path', file.webkitRelativePath)）。
容易踩的坑：
- 没做
if ('webkitRelativePath' in file)检查就直接读取，导致 Firefox 下报Cannot read property 'split' of undefined - 把
webkitRelativePath当作绝对路径处理，实际它只是相对于所选文件夹的路径（如"docs/report.pdf"），需和服务端约定好基础目录 - 未对路径做白名单校验（如过滤
../、空路径、非法字符），可能引发目录穿越或写入失败 - 假设所有浏览器都传了路径，结果 IE9 用户上传后所有文件挤在根目录，结构丢失
真正跨浏览器一致的行为只有：FileList 对象本身是可靠的，每个 File 对象的 name、size、type 都可用，但结构信息必须由前端补全或由用户二次确认。
为什么不用第三方库（如 WebUploader、Uppy）就能解决兼容性？
它们并不能“让 Firefox 支持文件夹选择”，只是把兼容性问题封装得更隐蔽。比如 WebUploader 的“文件夹上传”功能，在 Firefox 下实际走的是“多文件选择 + 手动拖拽目录到区域”，然后依赖用户把整个目录拖进来——这本质上不是浏览器能力，而是 UX 引导 + 文件系统 API（DataTransferItem.webkitGetAsEntry）的组合，而该 API 同样仅限 Chromium。
关键事实：
-
DataTransferItem.webkitGetAsEntry和webkitdirectory共享同一套底层权限模型，Firefox 不实现前者，自然也无法支持后者 - 所谓“全浏览器支持文件夹上传”的宣传，通常指“支持批量上传多个文件”，而非“支持选择一个文件夹并自动递归上传其全部子项”
- 政府/信创项目中遇到的“IE6–XP 环境”，连
webkitdirectory的影子都没有，此时唯一办法是客户端辅助工具（如 ActiveX 或 Electron 封装）或彻底放弃文件夹粒度，改用 ZIP 压缩包上传
最易被忽略的一点：路径解析逻辑一旦写死在前端，就等于把浏览器兼容性决策提前锁死了。应始终把 webkitRelativePath 视为可选附加值，而非结构必需字段。
