getasfilesystemhandle 已被彻底移除，chrome 95 起调用会报错；唯一合法获取句柄的方式是 drop 事件中调用 event.getfilesystemhandles()，且需用户按住 shift/option 键拖放原生文件系统对象。
getAsFileSystemHandle 在现代浏览器中基本不可用
这个方法在 Chrome 92+ 曾短暂存在，但 getAsFileSystemHandle 从未进入标准，且已在 Chrome 95 中被彻底移除。你现在调用它只会得到 undefined 或抛出 TypeError: item.getAsFileSystemHandle is not a function。别浪费时间查文档或调试它——它已经不存在了。
拖放文件后真正能拿到句柄的唯一路径是 use drop event + fileSystemAccess API
必须放弃从 DataTransferItem 入手的思路。正确做法是：监听 drop 事件 → 阻止默认行为 → 调用 event.getFileSystemHandles()（注意不是 item 方法）→ 这才是获取 FileSystemFileHandle 或 FileSystemDirectoryHandle 的合法入口。
-
event.getFileSystemHandles()返回 Promise> - 仅当用户在拖放时按住 Shift 键（Windows/Linux）或 Option 键（macOS），该方法才可能返回非空数组；否则仍为 []
- 即使成功，也只对“原生文件系统对象”有效（如桌面、访达、文件管理器直拖），不适用于粘贴板粘贴、input[type=file] 或 ZIP 内部文件
- 需要 HTTPS 环境和用户主动交互（不能在 onload 里静默调用）
常见错误：混淆 DataTransferItem.type 和实际文件类型
很多人以为 item.kind === 'file' 就能安全调用句柄相关方法，其实这是误导。即使 item.kind 是 file，item.getAsEntry()（已废弃）或 getAsFileSystemHandle()（已删除）也都失效了。现在能稳定读取内容的只有 item.getAsFile()，它返回标准 File 对象，但只是内存快照，不带持久句柄。
-
item.getAsFile()返回的File是一次性 Blob，无法后续写入或监听变更 - 若你需要后续读写权限（比如编辑后保存回原位置），必须走
showOpenFilePicker()或showSaveFilePicker()显式授权 - 拖放本身不触发权限授予，
getFileSystemHandles()只是“转交”系统已知的句柄，不是申请新权限
实操建议：优先用 showOpenFilePicker 替代拖放句柄需求
如果你的目标是“让用户选一个文件，之后能反复读写”，直接放弃拖放句柄幻想，改用 showOpenFilePicker —— 它返回真正的 FileSystemFileHandle，支持 createWritable()、getFile()、甚至 remove()（需权限）。
const [handle] = await window.showOpenFilePicker({
types: [{ description: 'Text files', accept: { 'text/plain': ['.txt'] } }]
});
const file = await handle.getFile(); // 获取当前内容
const writable = await handle.createWritable(); // 准备写入
await writable.write('new content');
await writable.close();
这比依赖拖放的不确定行为可靠得多。拖放适合快速导入（只读），持久操作请走显式 Picker。
真正容易被忽略的是：句柄生命周期与页面会话绑定，刷新页面后 handle 失效，必须重新授权或调用 navigator.storage.persisted() + requestPermission() 做持久化尝试——但这又引入额外兼容性判断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
