真正的权限校验必须放在「选完但未上传」阶段，依赖服务端预检接口；change事件中无法获取目标路径、用户身份及业务规则，任何前端拦截均无效；需调用/api/upload/permit传targetPath、fileCount、totalSize和fileExtensions，仅预检通过才执行上传。
浏览器本身不支持在选择文件夹阶段校验服务端权限，webkitdirectory 或 showDirectoryPicker() 触发时，前端连文件列表都还没拿到，更不可能知道用户有没有上传权限。真正的权限校验必须放在「选完但未上传」这个时间点，且必须依赖服务端预检接口。
为什么不能在 input change 时做权限判断
用户点击带 webkitdirectory 的 <input type="file"> 后，触发的是 change 事件，此时你只能拿到 FileList，里面每个 File 对象有 webkitRelativePath 和基础元数据，但：
- 没有目标上传路径（比如 /user/123/uploads）
- 没有用户身份上下文（token 可能过期、角色可能变更）
- 更没有服务端配额、目录写权限、文件类型白名单等业务规则
所以任何在 change 里做的“权限拦截”都是假的，只会误导用户或掩盖真实问题。
必须用 /api/upload/permit 做预检
用户选完文件夹、点击“开始上传”按钮后，上传逻辑应分两步走：先请求预检，再发真实上传。预检请求需携带关键上下文：
-
targetPath：用户要上传到的服务端路径（如/project/abc/），由前端根据业务逻辑拼出，不能由用户输入 -
fileCount和totalSize：从FileList遍历统计，用于配额校验 -
fileExtensions：提取所有文件扩展名去重（如[".pdf", ".jpg"]），供后端比对白名单
预检响应示例：
{"ok": false, "reason": "forbidden_path", "message": "您无权向该目录上传文件"}前端收到失败响应后，必须直接阻断后续上传，并把 message 展示给用户——不要只弹“上传失败”。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
FileSystemAccess API 下的权限校验时机
如果用 showDirectoryPicker()，流程稍不同：用户授权后你拿到的是 FileSystemDirectoryHandle，此时仍不能上传。你需要：
- 立即调用
dirHandle.resolve(entry)获取相对路径，构造targetPath - 用当前用户 token 请求
/api/upload/permit，传入路径和预估大小 - 只有预检通过，才进入遍历
dirHandle.values()+entry.getFile()+fetch()流程
注意：showDirectoryPicker() 是用户主动触发的权限授予行为，但它只代表“允许读取本地目录”，不代表“允许上传到服务端指定位置”。这两个权限完全独立，不能混为一谈。
容易被忽略的兼容性与安全细节
Chrome 支持 webkitdirectory，但 Firefox 和 Safari 不支持；showDirectoryPicker() 目前仅 Chrome/Edge 86+ 且仅限 HTTPS。这意味着：
- 你得 fallback 到单文件多选（multiple）或 ZIP 手动打包上传
- 所有预检逻辑必须在 fetch 前执行，不能靠 accept 或前端 JS 类型判断代替
- 服务端收到 multipart 请求后，仍要重新校验权限——因为两次请求之间，管理员可能已禁用该用户
