HTML原生不支持文件夹结构预览，因FileList扁平化且无isDirectory属性；仅能通过解析webkitRelativePath字符串模拟树形，但Firefox不支持该属性，且无法区分空目录与占位文件。
HTML 原生不支持「文件夹上传预览」——webkitdirectory 只能读取文件列表和路径，无法生成文件夹结构的可视化预览；File 对象本身不含目录节点信息，浏览器也不提供递归目录树 API。
为什么不能直接预览文件夹结构
用户选中一个文件夹后，event.target.files 返回的是扁平化的 FileList，每个 File 只有 name 和 webkitRelativePath（如 "docs/report.pdf" 或 "src/index.js"），没有「这是一个子文件夹」的标识。浏览器不会给你 isDirectory 属性，也没有 children 列表。
这意味着：你无法靠前端原生能力渲染出类似资源管理器那样的嵌套树形结构；所谓“预览”，只能是提取路径字符串、按 / 拆分、手动聚类模拟层级，但本质仍是文件列表的视觉整理，不是真实目录对象的映射。
-
webkitRelativePath在 Firefox 中始终为空，无法跨浏览器还原结构 - 即使 Chrome/Safari 返回了路径，也无法区分
assets/（空文件夹）和assets/.gitkeep（占位文件） - 没有 API 能获取文件夹修改时间、权限、图标等元数据
如何用路径字符串模拟“文件夹预览”
核心思路是把 webkitRelativePath 当作文本字段解析，提取各级父路径，再用 Map 或嵌套对象做归类。这不是真正的文件系统遍历，而是字符串路径的分组重建。
立即学习“前端免费学习笔记（深入）”；
示例逻辑：
const tree = new Map();
for (const file of files) {
const path = file.webkitRelativePath || file.name;
const parts = path.split('/');
let cursor = tree;
for (let i = 0; i < parts.length - 1; i++) {
const dir = parts[i];
if (!cursor.has(dir)) cursor.set(dir, new Map());
cursor = cursor.get(dir);
}
// 最后一级是文件名，存 file 对象或标记为 leaf
cursor.set(parts[parts.length - 1], { file, isFile: true });
}后续可用递归函数将 tree 渲染为带缩进的列表或折叠面板。注意：parts.length === 1 表示根目录文件，无需创建中间目录节点。
- 路径中含
../或绝对路径（如/etc/passwd）必须过滤，否则构成路径遍历风险 - 空路径（
""）或纯/需特殊处理，避免 map key 为 undefined - 同名文件在不同路径下会被正确隔离，但同名文件夹会合并——这是预期行为
预览时容易忽略的两个安全细节
用户点击「选择文件夹」后，你拿到的每个 File 对象看似可信，但路径字符串和文件内容都可能被恶意构造。不做校验就直接渲染或上传，会埋下漏洞。
- 对
file.webkitRelativePath做白名单校验：只允许字母、数字、-_./，拒绝..、\0、控制字符、Unicode 零宽空格 - 检查
file.size是否合理，超大值（如Number.MAX_SAFE_INTEGER）可能是伪造的，需结合实际读取验证 - 若预览中显示缩略图（如图片），必须用
URL.createObjectURL(file)而非FileReader.readAsDataURL()，避免内存爆炸；且在移除预览项时必须调用URL.revokeObjectURL()
真正需要“结构预览”的场景，该怎么做
如果业务强依赖可视化的目录树（比如让用户勾选子文件夹、拖拽重排、查看文件夹大小合计），纯前端基于 webkitRelativePath 的模拟很快会力不从心。这时应换思路：
后端提供轻量级目录探查接口（如 POST /api/folder/scan，传压缩包或签名 token），返回标准 JSON 树结构；前端只负责渲染。这样既规避浏览器限制，又统一了路径解析逻辑，还能做服务端权限控制和审计。
这个方案绕开了 webkitdirectory 的兼容性与语义缺失问题，也避免了前端反复解析路径字符串带来的维护成本。真正难的从来不是怎么画一棵树，而是谁来保证这棵树的节点真实存在、未被篡改、符合策略。
