iOS和绝大多数Android浏览器完全不支持webkitdirectory或directory属性，手机端仅能触发普通文件选择器，无法选择文件夹。
手机端不支持 webkitdirectory，别白费劲了
直接说结论：iOS 和绝大多数 Android 浏览器（包括 Chrome for Android、Firefox for Android、Safari）**完全不支持 webkitdirectory 或 directory 属性**。你在 PC 上能用的 <input type="file" webkitdirectory directory multiple>，在手机上点开只会弹出普通文件选择器，连文件夹图标都看不到。
这不是兼容性“差一点”，而是根本没实现。W3C 规范里 directory 本身就没被纳入正式标准，浏览器厂商只在桌面端做了实验性支持（且仅限 Chromium 和 Firefox），移动端全量缺席。
常见错误现象：
- 开发时在 Chrome 桌面调试正常，一换 iPhone 真机测试，
e.target.files.length始终是 1，file.webkitRelativePath全是空字符串 - 试图用
accept="*/*"+multiple模拟“选文件夹”，结果用户只能手动点选、反复点击，无法一次拉取整个目录树 - 在 Vue/React 里监听
change事件后发现files是扁平列表，毫无层级信息，根本没法还原原始结构
替代方案只有两个：压缩包上传 or 后端补路径
既然原生不支持，就得绕路。实际项目中真正可行的只有两条路径，选哪个取决于你的业务控制力：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用户侧妥协：引导用户先用手机文件管理器把目标文件夹打包成 ZIP（iOS 可用“文件”App 长按压缩，Android 多数厂商自带压缩功能），再上传 ZIP。前端用 JSZip 解析内容，提取文件名和二进制流，逐个提交或合并为 FormData 发送。优点是结构完整、路径可还原；缺点是多一步操作，老年用户或内网环境可能不会压缩
-
服务端兜底：前端仍用
multiple让用户尽可能多选文件（iOS 16+ Safari 支持一次选 20+ 文件），同时加一个文本输入框让用户手动填写“所属目录名”，比如project-v2/design/。后端接收时把该前缀拼到每个文件的存储路径里。适合内部系统或强流程管控场景，但无法保证用户填对、填全
别信“用 WebKit API 检测是否支持 directory”的判断逻辑——手机端检测永远返回 false，检测本身没意义。也不要用 capture 或 accept 试图诱导系统弹出文件夹视图，它们和目录选择无关。
真要尝试“伪文件夹上传”，必须处理好这三件事
如果产品硬性要求“看起来像传文件夹”，且你已确认只跑在部分高版本 Android（如 Samsung Internet 22+ 或 Kiwi Browser），那可以小范围试，但务必守住底线：
- 始终降级为
multiple模式：<input type="file" multiple accept="*/*">是唯一安全底线，所有手机都能走通 - 上传前校验
file.webkitRelativePath是否存在且非空：若为空，说明当前环境不支持目录结构，立即禁用路径相关逻辑，避免后端收到一堆同名文件覆盖 - 后端不能依赖前端传来的
webkitRelativePath做权限校验：它可被任意篡改（比如改写成../../etc/passwd），必须由后端做路径净化（如path.posix.resolve('.', relPath)再截断根外部分）
最常被忽略的坑：iOS 文件系统隔离与临时路径失效
即使用户成功选中多个文件，iOS 的 WebKit 会把它们拷贝到沙盒临时目录，路径形如 /private/var/mobile/Containers/Data/Application/xxx/tmp/xxx.jpg。这个路径只在本次页面生命周期有效，关页或切后台后立刻失效。
这意味着：
- 你不能在
change回调里用FileReader异步读取后再上传——iOS 下readAsArrayBuffer可能失败或返回空 - 不要缓存
file对象跨函数调用，尤其别在 Promise 链或setTimeout里延迟使用，容易触发 “Failed to read the 'content' property from 'Blob'” 错误 - 上传必须紧接在
change事件后同步构造FormData并发请求，中间别插入 DOM 操作或复杂计算
真实项目里，80% 的“手机上传失败”问题，根源不是代码逻辑，而是 iOS 这套临时路径机制没被正视。别等上线后被用户反馈“点了上传没反应”，先在真机上用 Safari 开发者工具看 console 有没有 Blob 相关报错。
