移动端HTML无法原生上传文件夹，因iOS/Android浏览器均不支持webkitdirectory且禁止网页遍历本地目录；仅能通过multiple多选、JSZip压缩上传或原生App等方案间接实现。
移动端 HTML 无法原生上传文件夹。 这不是写法问题，而是浏览器能力限制 —— 所有主流移动浏览器（iOS Safari、Chrome for Android、微信 WebView）都不支持 webkitdirectory，也不提供任何 API 让 JS 主动读取目录结构。
为什么 webkitdirectory 在手机上完全无效
这个属性只在桌面 Chrome/Edge/Safari 16.4+ 中可用，且依赖底层文件系统访问权限。移动端操作系统（iOS / Android）出于沙盒安全模型，禁止网页直接遍历本地目录树。即使你在 HTML 里写了 <input type="file" webkitdirectory>，iOS Safari 会忽略该属性，Android Chrome 则直接报错或退化为单文件选择。
- 真机测试确认：iOS 17–18、Android 12–14 上，
event.target.files.length永远为 0 或仅返回根目录下的单个文件（如果用户手动点选了某个文件） - 开发者工具模拟“移动端”没用——它只是缩放和 UA 伪装，不模拟真实权限限制
- Electron 或 PWA 环境也默认禁用，需显式开启
webPreferences.fileSystemAccess: true，但此配置在标准 WebView 中不可用
移动端能做的实际替代方案
你只能引导用户逐个选择文件，或用变通方式逼近“批量上传”体验：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
multiple+ 明确accept：例如<input type="file" multiple accept=".pdf,.docx,.xlsx">，iOS 15+ 和较新安卓可支持文档多选（但非目录递归） - 针对图片场景，用
capture+multiple：如<input type="file" accept="image/*" multiple capture="environment">，调起相册并允许多选照片 - 放弃“文件夹”概念，改用后端生成临时上传链接 + 客户端 ZIP 打包：前端用 JSZip 压缩用户选中的多个文件，再上传 ZIP；服务端解压还原结构（注意内存和超时限制）
- 对重度用户，推荐配套轻量 App（如用 Capacitor 封装），通过原生 API 访问目录并桥接回 Webview
别踩的兼容性深坑
很多方案看似可行，实测会在特定机型/系统上静默失败：
立即学习“前端免费学习笔记（深入）”；
- 不要给
<input>加webkitdirectory后还指望 iOS 有反应——它连控制台警告都不会抛，就是没效果 - 不要监听
change后去查files[0].webkitRelativePath：移动端该属性永远是undefined，读它不会报错但拿不到值 - 避免用
FormData.append("file", file, "path/to/file.txt")传路径名：移动端选的文件没有相对路径信息，第三个参数会被忽略或导致后端解析异常 - 微信内置浏览器（X5）会拦截
multiple和部分accept值，必须真机调试，不能只信模拟器
真正需要保留完整目录结构的业务场景，移动端必须接受“降级为单文件多次上传”或转向原生能力。把“上传文件夹”当作桌面专属功能来设计，比硬凑移动端兼容更可靠。
