离线安装插件仍受VSCode权限模型约束：必须在package.json中显式声明capabilities（如"workspace": {"read": true}），且每次访问新路径（如C: emp oo.txt与bar.txt）需单独授权；WSL下须用vscode.workspace.fs而非Node.js fs，并确保/etc/wsl.conf启用metadata选项。
离线安装的插件，和在线装的一样受 VSCode 权限模型约束——不是“装上了就能随便读写文件”，权限依然由 capabilities 声明 + 用户路径授权双控决定。
为什么插件装好了却读不了 workspace 外的文件？
离线安装不改变 VSCode 的安全模型。1.86+ 版本后，插件必须在 package.json 中显式声明 "capabilities": { "workspace": { "read": true, "write": true } }，否则调用 vscode.workspace.fs.readFile() 会静默失败或抛出 OperationNotSupportedError。
- 只写
"workspace": true已被弃用，必须是对象结构 - 声明了
"read": true不代表能读任意路径——首次访问C: emp oo.txt会弹窗授权，但C: empar.txt是另一个独立路径，仍需再次授权 - 硬编码路径（如
vscode.Uri.file('C:\config\settings.json')）几乎必然失败，除非该路径已获用户明确授权
WSL 下离线插件读写 Windows 文件总失败？
这不是网络或离线导致的问题，而是跨系统元数据不一致。在 WSL 中直接用 Node.js fs 模块操作 /mnt/c/Users/xxx 路径，会因权限映射丢失、执行位（x）被忽略而失败。
- 必须统一走
vscode.workspace.fsAPI，它内部做了 NTFS/POSIX 元数据桥接 - 确保 WSL 配置启用了 metadata：
/etc/wsl.conf中含options="metadata,uid=1000,gid=1000" - 别在插件里调用
chmod +x—— Windows NTFS 不支持执行位，该操作在 WSL 中也仅临时生效
离线安装后插件功能异常，该查哪些权限相关点？
离线环境容易掩盖权限问题，因为错误日志更少、弹窗更易被忽略。遇到功能缺失（比如通义灵码无法读当前文件、Pylance 不加载），优先排查：
- 右下角状态栏是否显示
Extensions disabled by policy—— 企业策略可能禁用全部扩展能力 - 插件是否声明了
"fileSystemProvider"或"virtualWorkspaces"等高级 capability，但未在离线包中正确打包 - 用户是否在首次调用时点了“拒绝”而非“允许”，且后续没再触发授权流程（VSCode 不提供重试入口，只能模拟新路径访问）
- 检查
vscode.env.appRoot可读，但vscode.Uri.file(...)报错：说明 capability 缺失，不是路径问题
真正难调试的是：用户点了“允许”，你以为万事大吉，其实只是授权了那个完整路径字符串——多一个斜杠、大小写差异、符号链接展开后的实际路径，都会被视为全新域，重新卡住。这不是 bug，是设计使然。
