webkitdirectory仅Chrome 19+和Edge 79+稳定支持；Safari、Firefox、IE均不支持，且失败静默无提示；无跨浏览器原生替代方案，需明确提示用户限Chromium系浏览器。
是的，webkitdirectory 当前仅在 Chromium 系列浏览器（Chrome、Edge）中稳定可用，Safari 和 Firefox 均不支持。
哪些浏览器实际能用 webkitdirectory
这个属性本质是 WebKit 引擎的私有扩展，后来被 Blink（Chrome/Edge）继承并保留，但从未成为标准 API：
- ✅ Chrome 19+（稳定支持，包括最新版）
- ✅ Edge 79+（基于 Chromium，同步支持）
- ❌ Safari（所有版本）：明确不支持，调用
<input type="file" webkitdirectory>不会触发文件夹选择，且无任何降级提示 - ❌ Firefox（所有当前版本）：已移除早期实验性
directory支持，webkitdirectory完全无效 - ❌ 所有 IE 版本：不识别该属性，行为等同于普通单文件
<input type="file">
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 特性检测自动兜底，因为不支持时连入口都不可见。
