webkitdirectory是否只支持Chrome？

先说一个客观结论：当前webkitdirectory 仅在 Chromium 系浏览器（Chrome 19+、Edge 79+）中稳定可用，Safari 和 Firefox 均不支持，且失败时没有任何提示。更棘手的是，目前没有跨浏览器的原生替代方案——因此在实际部署这一功能时，必须在界面上明确告知用户“请使用 Chrome 或 Edge”。

没错，webkitdirectory 当前仅在 Chromium 系列浏览器（Chrome、Edge）中稳定可用，Safari 和 Firefox 均不支持。

哪些浏览器实际能用 webkitdirectory

该属性本质上是 WebKit 引擎的私有扩展，后被 Blink（Chrome/Edge）继承并保留，但从未成为标准 API。以下是实际支持情况：

• Chrome 19+（稳定支持，含最新版本）
• Edge 79+（基于 Chromium，同步支持）
• Safari（所有版本）：明确不支持，调用 不会触发文件夹选择，且无任何降级提示
• Firefox（所有当前版本）：早期实验性的 directory 支持已被移除，webkitdirectory 完全无效
• 所有 IE 版本：不识别该属性，行为等同于普通单文件

webkitdirectory 的典型错误现象

不少开发者以为“加了属性就一定有效”，结果在非 Chrome 环境下静默失败，调试起来颇为棘手：

• 点击 input 后弹出的对话框仍是单文件选择界面，根本没有“选择文件夹”的选项
• event.target.files 返回空的 FileList，或仅包含根目录下的顶层文件（子目录全部被忽略）
• 控制台不报错、不警告——失败完全静默，极易漏测
• 若依赖 webkitRelativePath 解析目录结构，在 Firefox/Safari 下该属性会返回 "" 或 undefined

有没有替代方案？

遗憾的是，目前没有标准且跨浏览器的原生文件夹上传能力。可行的路径主要有三条：

• 使用 showDirectoryPicker()（需 HTTPS + 用户手势触发）：但仅 Chromium 支持，Safari/Firefox 仍不支持；且它返回的是 FileSystemDirectoryHandle，非传统 File 对象，后端还需适配流式读取。
• 放弃文件夹选择，改用多文件选择（multiple）+ 前端 ZIP 打包（如 JSZip）：让用户手动压缩再上传，兼容性无问题，但体验上有割裂感，大文件易卡死。
• 服务端提供 WebDAV 或专用客户端：绕过浏览器限制，但已脱离纯网页场景。

综合来看，若要落地文件夹上传功能，需默认接受“仅限 Chrome/Edge”这一现实，并在 UI 上明确提示浏览器要求——不要寄望于 JS 特性检测自动兜底，因为不支持时连入口都看不到。