必须使用 vscode.workspace.fs api 配合 context.globalstorageuri 或 context.storageuri 读写数据，而非硬编码 .vscode/extensions 路径；因 --extensions-dir 可被用户覆盖且插件无法动态获取该值，硬编码会导致跨平台失效与权限错误。
如何在插件代码里安全获取用户主目录
VSCode 插件运行在 Node.js 环境中，但不能直接用 process.env.HOME 或 process.env.USERPROFILE —— 这些变量在某些沙箱场景（如远程开发、WSL、容器）下可能为空或不可靠。正确做法是调用 VSCode 提供的 API。
- 优先使用
vscode.env.appRoot获取编辑器安装根路径（只读，不建议存用户数据） - 真正需要用户数据位置时，应通过
vscode.workspace.getConfiguration().get('extensions')配合vscode.ExtensionContext.extensionPath推导，但更稳妥的是用require('os').homedir() - 若需访问用户配置目录（如保存 token、缓存），推荐组合：
require('path').join(require('os').homedir(), '.vscode', 'extensions')—— 注意这只是默认路径，实际可能被--extensions-dir覆盖
插件安装路径是否可被 runtime 动态读取
不可以。VSCode 不提供公开 API 返回当前 --extensions-dir 的实际值。插件启动时，VSCode 已完成插件扫描并加载，但不会把该路径暴露给扩展进程。
- 插件无法得知自己被装在哪个物理路径下，
context.extensionPath返回的是该插件自身的子目录（例如/path/to/extensions/ms-python.python-2023.10.1），不是父级 extensions 目录 - 试图用
fs.readdirSync(path.dirname(context.extensionPath))可能失败：该目录可能被权限限制，或在某些系统（如 macOS App Sandbox）下不可访问 - 如果插件需要写入共享缓存，应改用
context.globalStorageUri或context.storageUri—— 这些路径由 VSCode 管理，跨平台且稳定
为什么插件里不要硬编码 .vscode/extensions
因为这个路径只是默认值，用户可通过命令行参数覆盖，而插件无权感知或干预该行为。硬编码会导致路径失效、文件找不到、甚至权限错误。
- Windows 用户可能设为
D:\vscode\extensions，macOS 用户可能挂载到/Volumes/Data/vscode/extensions，Linux 用户可能用符号链接指向/opt/vscode/extensions - 企业部署中常配合 CI/CD 预置插件目录，路径完全脱离用户主目录结构
- 若插件尝试读取其他插件的
package.json或依赖文件，硬编码路径会直接 crash，且无法 fallback
插件需要读写自身数据时该用什么路径
用 context.globalStorageUri 或 context.storageUri，而不是拼接任何文件系统路径。
-
context.globalStorageUri：跨工作区全局可用，适合保存用户级设置、token、长期缓存 -
context.storageUri：按工作区隔离，适合保存项目相关状态（如上次打开的视图、临时索引） - 两者返回
vscode.Uri对象，必须配合vscode.workspace.fsAPI 读写，不能直接传给fs.readFile - 示例：
await vscode.workspace.fs.writeFile(context.globalStorageUri.with({ path: context.globalStorageUri.path + '/config.json' }), buffer)
--extensions-dir，也别试图去猜**。所有与路径相关的操作，都该交给 VSCode 自己的存储 API 去处理。
