HTML文件夹上传需后端配合，纯前端无法实现；webkitdirectory非标准且仅Chromium支持，Firefox/Safari不兼容；必须通过后端接收多文件、校验路径与权限，并防范遍历攻击。
HTML 文件夹上传需要后端配合，纯前端无法实现
浏览器出于安全限制，<input type="file"> 默认不支持选择文件夹（webkitdirectory 是非标准且仅限 Chromium 内核），更无法直接读取目录结构或递归上传子文件。所谓“文件夹上传”，实际是用户手动勾选多个文件，或依赖后端提供 WebDAV、FTP、或自定义接口接收分片/多文件请求。
常见错误现象：Failed to execute 'readAsDataURL' on 'FileReader': parameter 1 is not of type 'Blob'——误把 DirectoryEntry 当作 File 处理；或在 Safari 中完全无响应——webkitdirectory 被忽略。
- 若必须支持文件夹拖拽上传，需用
event.dataTransfer.items遍历FileSystemFileEntry，逐个调用file()获取真实File对象 - 不要依赖
webkitdirectory做生产逻辑，它不被 Firefox、Safari 支持，且无法获取相对路径 - 服务端必须明确支持多文件 POST（如
multipart/form-data中含多个name="files"字段）
Node.js + Express 实现带权限校验的文件夹级上传接口
权限控制不在 HTML 或前端 JS 里做，而在接收上传的路由中完成：验证登录态、检查用户是否有目标目录写入权、限制文件类型与总大小。
使用场景：教育系统家长端上传打卡材料、考试报名系统提交扫描件包。
立即学习“前端免费学习笔记（深入）”；
- 用
multer的array('files')接收多个文件，而非single() - 在
fileFilter回调中检查file.originalname是否含非法路径（如../），防止路径遍历 - 通过中间件读取 JWT 或 session，比对
req.user.role和目标目录的allowed_roles配置项 - 示例校验逻辑：
if (file.size > 5 * 1024 * 1024) return cb(new Error('单文件不能超过 5MB'))
前端上传时如何保留原始文件夹结构？
浏览器原生不传递路径信息，所谓“结构”只能靠约定或额外字段模拟。比如打包成 ZIP 后上传，或让前端在上传每个文件前拼接虚拟路径前缀。
容易踩的坑：直接用 file.webkitRelativePath——它只在拖拽文件夹到 <input> 时存在，且 Chrome 86+ 已弃用；Firefox 完全不提供。
- 推荐做法：让用户先压缩为 ZIP，后端用
node-stream-zip解压并校验内部路径 - 若坚持单文件流式上传，前端可为每个
File对象附加metadata.path = 'materials/idcard.jpg'，和服务端约定该字段含义 - 务必在服务端重写存储路径，禁止直接拼接
path.join(uploadDir, file.metadata.path)，防止越权写入
OneDrive 或类似云盘能否替代自建上传权限系统？
可以，但控制粒度不同。微软 OneDrive 现已支持在线编辑 HTML/Markdown，但它不提供「按用户上传到指定子目录并自动绑定权限」的 API 级能力。它的权限模型基于 SharePoint 权限组或链接分享设置，无法做到每个家长只看到自己孩子的上传入口。
性能影响：调用 OneDrive Graph API 上传大文件夹需分块、续传、token 刷新，延迟高于内网直传；兼容性上，Graph API 要求 OAuth2 授权流，不适合微信内嵌 H5 这类受限环境。
- 适合场景：内部办公系统，管理员统一管理文件夹，无需细粒度隔离
- 不适合场景：高考报名 H5、打卡系统这类面向海量终端用户的 C 端应用
- 如果真要用，必须自行封装上传逻辑，并在回调中校验
response.headers['Content-Range']和uploadUrl有效性
权限控制的核心永远在服务端路径解析与身份核验环节，前端任何“隐藏按钮”或“禁用 input”都形同虚设。最容易被忽略的是：未对 ZIP 解压后的内部文件路径做二次规范化处理，导致 ../../../etc/passwd 类攻击绕过首层校验。
