VSCode插件文件系统访问需同时满足能力声明与用户运行时授权，缺一不可；未声明或未获路径粒度授权时，vscode.workspace.fs调用将静默失败或抛错。
VSCode 插件在访问文件系统时，不是“能写就能写”，而是受双重权限控制：插件能力声明 + 用户运行时授权。跳过任一环节，vscode.workspace.fs.readFile() 就会静默失败或抛 OperationNotSupportedError。
capability 声明不全导致 fs 调用静默失败
VSCode 1.86+ 强制要求插件在 package.json 中显式声明所需能力，不再默认开放任何文件操作权限。
-
"workspace"必须以对象形式声明，例如"workspace": { "read": true, "write": true }；旧写法"workspace": true已被弃用 - 仅声明
"read": true时，vscode.workspace.fs.writeFile()仍会报错，哪怕路径合法 -
"globalState"和"userData"用于插件自身配置存储，与工作区文件无关，别混淆用途 - 未声明
"env"时，调用vscode.env.appRoot可读，但vscode.env.clipboard.readText()会直接拒绝
WSL 下必须用 vscode.workspace.fs，不能用 Node.js fs
在 WSL 环境中，插件若直接使用 fs.readFile()（Node.js 原生模块）读取 /mnt/c/... 路径，大概率因跨子系统权限模型失效而失败——即使用户已授权该路径。
- 必须统一走
vscode.workspace.fsAPI，它会自动桥接 WSL 权限上下文 -
vscode.Uri.file('/mnt/c/users/alice/file.txt')是合法 URI，但需确保该路径已获用户授权（见下一条） - 不要在
vscode.workspace.fs调用前做fs.statSync()判断，这会导致权限校验绕过失败
路径粒度授权：C: emp oo 和 C: empar 是两个不同域
VSCode 不按盘符或父目录授权，而是精确到完整路径字符串。用户点一次“允许”，只对那个具体路径生效。
- 首次访问
vscode.Uri.file('C:\temp\config.json')会弹窗；再访问C:\temp\log.txt会再次弹窗 - 硬编码路径（如拼接
os.homedir() + '/Downloads'）必须先调vscode.workspace.fs.stat()并捕获FilePermissionDeniedError，再用vscode.window.showOpenDialog()引导用户选中同级目录获得授权 -
C:\Program Files、C:\Windows类路径永远无法获得授权，插件无权绕过 Windows ACL，别尝试
远程容器中挂载目录的权限映射陷阱
当插件运行在 VS Code 远程容器中，且容器挂载了宿主机目录（如 /workspace），文件操作权限取决于容器内 UID/GID 与宿主机文件所有者的匹配程度。
- 宿主机文件属主 UID=1000，但容器默认用户是 root（UID=0）→ 插件调用
vscode.workspace.fs.writeFile()失败 - 解决方案：在
.devcontainer/devcontainer.json中配置"remoteUser": "devuser"，并确保该用户 UID 与宿主机一致 - 更稳妥做法：在容器启动脚本中运行
chown -R devuser:devuser /workspace，避免插件因权限不足静默跳过写入
最易被忽略的一点：即使 capability 声明完整、路径也获授权，vscode.workspace.fs 在远程容器中仍可能因挂载选项缺失 metadata 而无法保留执行权限（如 chmod +x）。此时需检查 WSL 的 /etc/wsl.conf 或 Docker 的 mount_opts 是否启用元数据支持。
