FileSystemProvider需显式注册自定义scheme并声明onFileSystem激活事件，stat()和readDirectory()返回值格式必须严格符合要求，路径统一用正斜杠，readText()须异步且支持分块读取，watch()必须真实监听变更源。
FileSystemProvider 是 VS Code 插件中实现自定义文件系统行为的核心接口，它让你能在不落地磁盘的前提下，把远程资源、内存数据、甚至计算结果“伪装”成普通文件夹和文件，供编辑器原生识别和操作。
你得先明确一点：VS Code 不会自动加载你的 FileSystemProvider。它必须被显式注册，并绑定到一个自定义 URI scheme（比如 vscode-vfs:// 或 myapp://），否则所有调用都会 fallback 到默认的 file:// 系统，压根不会进你的逻辑。
注册 FileSystemProvider 必须配对 scheme 和 activationEvent
注册本身在插件激活时完成，但 VS Code 只有在 URI 匹配对应 scheme 且触发了正确的激活事件后，才会加载你的 provider 实例。
- 在
package.json中声明自定义 scheme："contributes": { "filesystems": ["myapp"] } - 同时必须添加激活事件：
"activationEvents": [ "onFileSystem:myapp", "onCommand:myapp.openRoot" ]
漏掉onFileSystem:myapp，哪怕你代码里调用了workspace.registerFileSystemProvider，VS Code 也根本不会初始化它。 - 注册时机不能太早——必须等
activate回调执行后，且确保vscode.workspace已就绪；否则会报Cannot read property 'registerFileSystemProvider' of undefined。
stat() 和 readDirectory() 的返回值结构容易出错
stat() 返回的 FileStat 对象里，mtime 和 ctime 必须是毫秒级时间戳（不是秒），且 type 字段只能是 FileType.File、FileType.Directory 或 FileType.Unknown —— 传字符串或错位枚举值会导致整个目录树无法展开。
-
readDirectory()返回的是[string, FileType][]元组数组，不是对象数组。写成{ name: 'foo', type: FileType.File }会静默失败，资源管理器显示空文件夹。 - 路径分隔符统一用正斜杠
/，即使在 Windows 上也要避免\；URI 中的路径必须以/开头（如myapp://root/sub/），否则vscode.Uri.joinPath拼接会出错。 - 如果某次
readDirectory返回空数组，VS Code 会认为该目录确实为空，不会反复请求；但若因网络错误没返回、或抛出未捕获异常，则 UI 卡住或显示“Loading…”无限转圈。
性能敏感点：不要在 readText() 里做同步阻塞操作
用户双击打开一个虚拟文件时，VS Code 默认调用 readText()（本质是 open() + read() + close()）。这个流程必须异步，且不能依赖同步 HTTP 或 fs.readFileSync。
- 浏览器环境（如 VS Code for Web）下，
fetch是唯一可行方式；Node.js 环境（桌面版插件）可用got或node-fetch，但别用require('fs').readFileSync—— 它会让整个渲染进程卡顿。 - 大文件要支持分块读取：实现
open()返回一个FileHandle，再在read()中按 offset/length 控制范围；否则一次性加载 10MB 内存文本会触发 OOM 告警。 - 缓存策略自己管：VS Code 不帮你缓存内容。建议用
Map<vscode.uri string></vscode.uri>存最近读取的文本，但记得设 TTL 或监听onDidChangeFileSystem事件清理。
真实项目里最常被忽略的，是 watch() 方法的实现。VS Code 在资源管理器里拖动、刷新、甚至切换 Git 分支时，都可能触发 watch 请求。如果你返回空或直接 resolve，编辑器就收不到文件变更通知——用户改了远程配置却看不到高亮更新，问题极难定位。这地方必须对接真实的变更源（比如 WebSocket、SSE 或轮询），而不是假装支持。
