File System Access API 是需用户授权、仅限安全上下文的现代浏览器API，非HTML原生功能；必须由用户手势触发，在HTTPS/localhost下运行，返回句柄而非路径，不支持自动读取同目录文件，目标是PWA本地文件管理而非替代Node.js fs模块。
HTML 本身不能直接访问操作系统文件系统，File System Access API 是浏览器提供的一个**受限制、需用户主动授权**的现代 Web API，不是 HTML 标签或属性，也不是“写个 <input type="file"> 就能读硬盘”的能力。
File System Access API 必须在安全上下文中运行
该 API 只能在 https:// 或 localhost 下使用，file:// 协议下完全不可用——哪怕你本地双击 HTML 文件，调用 window.showOpenFilePicker() 也会直接抛出 SecurityError。
- Chrome/Edge 115+、Firefox 125+（有限支持）、Safari 尚未实现
- 必须由用户手势触发（如点击按钮），不能在页面加载时自动调用
- 每次访问都弹出系统级选择框，用户选中后才返回一个
FileSystemHandle，不是路径字符串 - 拿到的 handle 是“句柄”，不是真实路径；无法遍历父目录，也不能用
fs.readFile那类 Node.js 方式操作
showOpenFilePicker 和 showSaveFilePicker 的行为差异
showOpenFilePicker() 返回可读的 FileSystemFileHandle，showSaveFilePicker() 返回可写的 FileSystemFileHandle，但两者都不等价于“打开文件管理器随便点”。
-
showOpenFilePicker({ multiple: true })允许选多个文件，但每个仍需单独getFile()获取 Blob -
showSaveFilePicker({ types: [{ description: 'JSON', accept: { 'application/json': ['.json'] }] })会限制保存类型并预填扩展名 - 不传
types参数时，Chrome 默认只显示常见文档类型（.txt/.html/.json 等），不会列出 .log 或自定义后缀，除非用户手动切换“所有文件” - 调用
handle.createWritable()后必须显式write()+close()，否则文件内容为空
为什么 fetch('./data.json') 和 File System Access API 完全不是一回事
fetch('./data.json') 是 HTTP 请求，依赖服务器返回资源；File System Access API 是绕过网络、直接与用户本地文件交互的机制——但它不解决“自动读同目录 JSON”这种需求，反而让这事变得更重。
立即学习“前端免费学习笔记（深入）”；
- 前者失败是因为
file://协议被浏览器禁止跨源请求；后者失败是因为没授权、没用户点击、或环境不合法 - 想“启动就加载 config.json”，只能走 HTTP 服务（如
python3 -m http.server）；想“让用户选一个配置文件来导入”，才用showOpenFilePicker - API 不提供同步读写，所有操作都是 Promise 驱动，
await fileHandle.getFile()后还得await blob.text()才拿到字符串 - 没有
readdir、stat、rm等能力；所谓“目录访问”需用showDirectoryPicker()，且用户必须手动勾选“包含子文件夹”才能递归获取
真正容易被忽略的是：这个 API 的设计目标从来不是替代 Node.js 的 fs 模块，而是让 PWA 能像桌面应用一样保存项目到本地、打开用户指定的工程文件。如果你的场景是“开发时读本地 mock 数据”，别碰它——老实用 http://localhost 加 fetch；只有当你的应用明确需要用户持续管理一组本地文件（比如 Markdown 笔记工具、离线音视频编辑器），才值得引入并处理它的权限流、兼容降级和错误提示逻辑。
