--extensions-dir 是控制 VSCode 插件路径的唯一有效方式，需完全关闭后通过命令行或固化快捷方式启动才生效；settings.json 中的 extensions.installDir 仅为只读显示字段，修改无效。
extensions-dir 参数是控制 VSCode 插件路径的核心开关，但它不是“设了就一劳永逸”的配置。默认路径卡在用户主目录下，一旦插件数量上去、版本频繁更新，.vscode/extensions 目录就会膨胀得难以维护，甚至拖慢启动速度。关键不在“换不换路径”，而在于“换完之后怎么让它真正起效且不翻车”。
如何用 code --extensions-dir 指定有效路径
这个命令行参数必须在 VSCode **完全关闭后** 重新启动时生效，热重载或窗口重启无效。常见错误是改完路径后只点了“重新加载窗口”，结果还是走旧目录。
- Windows 用户注意：路径中含空格或中文时，必须用双引号包裹，例如
code --extensions-dir "D:\VS Code Extensions" - macOS/Linux 用户需确保目标目录有读写权限，尤其挂载卷（如
/Volumes/Data）可能默认禁用执行权限，chmod -R 755不能少 - 路径末尾不要加斜杠——
--extensions-dir ~/.vscode/ext/和--extensions-dir ~/.vscode/ext在某些版本里会被视为不同路径，导致插件重复安装 - 验证是否生效：启动后打开命令面板，运行
Developer: Open Extensions Folder，看打开的是否是你指定的目录
settings.json 里配 extensions.installDir 是个坑
VSCode 官方文档早已明确标注：extensions.installDir 是**只读配置项**，仅用于显示当前插件安装位置，写入该字段不会改变行为。很多教程误把它当可配置项，结果用户改了 settings.json 却发现插件照旧装进默认目录。
- 真实生效的唯一方式只有启动参数
--extensions-dir或环境变量VSCODE_EXTENSIONS - 如果
settings.json里手动写了"extensions.installDir"，建议删掉，避免误导自己或团队成员 - 想让所有团队成员统一路径？别靠 settings.json 同步，而是用脚本封装启动命令，比如 macOS 的
vscode-customshell alias
多工作区 + 自定义路径的兼容性陷阱
当你用 --extensions-dir 指向一个共享路径（比如 NAS 或外置 SSD），多个 VSCode 实例同时读写同一插件目录，会触发文件锁冲突，表现为插件更新失败、package.json 读取报错或扩展图标变灰。
- VSCode 不支持插件目录的并发写入，哪怕只是两个窗口——它假设该目录是独占的
- 若需多项目共用插件，优先考虑用
extensions.autoUpdate: false+ 手动同步，而非强行共享目录 - 企业级部署推荐做法：每个开发机用本地
--extensions-dir，再通过配置管理工具（Ansible / Nix）批量部署插件包，而不是依赖实时网络挂载 - 特别注意：Remote-SSH 连接时，
--extensions-dir指向的是远程机器路径，不是本地；本地插件不会自动同步过去
插件路径变动后，哪些地方会悄悄失效
路径一换，最隐蔽的问题往往不出现在插件本身，而出现在你依赖它的其他配置里。
-
tasks.json或launch.json中硬编码了插件生成的输出路径（比如 Prettier 格式化后的临时文件路径），这些路径不会随--extensions-dir自动更新 - 某些插件（如 ESLint、TypeScript）会在首次运行时缓存
node_modules路径，换目录后可能仍尝试从旧extensions子目录加载依赖，导致“插件已启用但功能不响应” - 自定义
extensions-dir后，Developer: Show Running Extensions面板仍能正常显示，但右键“重新加载”可能失败——因为插件进程实际是从新路径加载的，而 UI 缓存了旧路径元信息 - 最易忽略：VSCode 的“扩展推荐”机制（
.vscode/extensions.json）只管安装提示，不管路径；它推荐的插件仍会按你当前启动方式决定装到哪
路径管理不是单纯挪个文件夹的事。它牵扯启动链、缓存策略、跨平台权限和协作一致性。每次改动前，先问一句：这个路径，是给人看的，还是给 VSCode 进程真正读写的？
