webkitdirectory 仅在 chromium 和 safari 16.4+ 中有效，firefox 不支持；需用 触发文件夹选择，获取扁平化 filelist，依赖 webkitrelativepath 还原路径，服务端需接收带路径的 multipart 文件。
不能直接用 webkitdirectory 做跨浏览器文件夹上传，它只在 Chromium（Chrome/Edge）和 Safari 16.4+ 中有效，Firefox 已明确不支持，且行为与你直觉可能相反：选中的是“文件夹”，但 JS 拿到的是一堆扁平化的 File 对象，没有目录结构，也没有递归遍历能力。
怎么写 HTML 才能触发「选择文件夹」对话框
必须同时满足三个条件，缺一不可：
-
type="file"是基础，不能省 -
webkitdirectory属性要写，它是实际起效的关键（directory属性可加可不加，Firefox 旧版曾支持，现在基本无效） -
multiple必须显式加上——否则即使点了文件夹，e.target.files可能为空、或只返回一个空字符串（不是File），根本拿不到任何文件
最简可用写法是：
<input type="file" webkitdirectory multiple>。别加
accept，它对文件夹无效；别设 value，JS 赋值会被忽略；别用 display: none 隐藏 input，否则点击事件失效。
为什么拿到的 FileList 是扁平的，且没有路径层级
浏览器不会把整个文件夹树塞给你。webkitdirectory 的真实行为是：用户选中一个根文件夹后，浏览器递归遍历其下所有**文件**（不含子目录对象本身），然后把它们全部塞进 e.target.files，形成一个没有嵌套结构的 FileList。
想还原原始路径，唯一依据是每个 File 实例上的 webkitRelativePath 字段，比如 "src/utils/helper.js" 或 "images/logo.png"。这个字段在 Firefox 中始终为空，所以不能只靠它做路径解析。
常见错误现象：
• 直接用 file.name 当作完整路径，结果所有文件都显示为同名（如都叫 index.html）
• 尝试读取 file.path，得到 undefined（该字段早已被 Chromium 移除）
• 以为 e.target.files 包含子目录对象，结果遍历时发现全是文件，没有目录项
如何安全地上传文件并保留目录结构
服务端需要能接收带路径信息的文件流，前端则需用 FormData 显式传路径作为文件名：
- 遍历
e.target.files，对每个file提取file.webkitRelativePath || file.name - 构造
FormData时，用路径字符串作为第三个参数：formData.append('files', file, path) - 不要用
file.name作为 key，否则同名文件会覆盖；统一用'files'作为字段名，后端按 multipart 多文件解析即可
示例片段：
const files = Array.from(e.target.files);<br>const formData = new FormData();<br>files.forEach(file => {<br> const path = file.webkitRelativePath || file.name;<br> formData.append('files', file, path);<br>});
有没有更现代、更标准的替代方案
有，但兼容性差：showDirectoryPicker() API 是 W3C 标准方案，返回 FileSystemDirectoryHandle，支持真正的递归遍历和元数据判断（isFile()/isDirectory()）。但它要求页面运行在 https:// 或 localhost 下，且目前仅 Chrome/Edge 112+、Safari 16.4+ 支持，Firefox 仍无计划支持。
这意味着：如果你的产品必须支持 Firefox 或 HTTP 环境，webkitdirectory 仍是唯一现实选择；如果只面向现代 Chromium 用户，showDirectoryPicker() 更可控、更安全，但得自己写递归逻辑，不能偷懒。
真正容易被忽略的一点：无论用哪种方式，浏览器都不会给你「文件夹对象」本身——你永远只能拿到文件内容或路径字符串，无法获取权限、修改时间、访问控制列表等原生文件系统元数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
