VSCode的code命令失效需手动添加到PATH，通过Shell Command命令自动配置；-r等价于--reuse-window，不重载设置；--goto支持行列精确定位；--disable-extensions用于排查扩展冲突。
code命令打不开VSCode或提示“command not found”
这是 macOS 和 Linux 用户最常遇到的问题，本质是 code 命令没被加入系统 PATH。Windows 通常自动注册（尤其用 Installer 安装时），但 macOS 用 .zip 解压安装、或 Linux 用 tarball 安装，默认不写入 shell 配置。
解决方法很简单：打开 VSCode，按 Cmd+Shift+P（macOS）或 Ctrl+Shift+P（Windows/Linux），输入 Shell Command: Install 'code' command in PATH 并回车执行。VSCode 会自动修改你的 ~/.zshrc（macOS Catalina+ 默认）、~/.bash_profile 或 ~/.profile，追加类似这行：
export PATH="$PATH:/Applications/Visual Studio Code.app/Contents/Resources/app/bin"
执行完后重启终端，或运行 source ~/.zshrc（根据你实际 shell 配置文件名调整）。
- 如果执行命令后仍报错，检查 VSCode 是否在默认路径 —— 比如你把它拖进了
/Applications；若放在桌面或其它位置，VSCode 可能无法正确推导 bin 路径 - Linux 用户注意：部分发行版（如 Ubuntu 的 Snap 版本）自带的 VSCode 不提供
code命令，建议卸载后从官网下载 .deb 或 .tar.gz 安装包 - 执行命令后终端里
which code应该返回有效路径，否则 PATH 没生效
code -r 和 code --reuse 的区别与误用场景
code -r 是最常被误写的参数 —— 它其实等价于 code --reuse-window，意思是“如果已有窗口打开，就复用它，不要新建窗口”。但它**不是**“强制重载当前窗口”或“刷新工作区”，这点很多人混淆。
典型误用：改了 settings.json 后想立刻生效，就敲 code -r .，结果什么都没变。因为 -r 只影响窗口行为，不触发配置重载。
- 真正需要重载设置？改完后按
Cmd+Shift+P→ 输入Developer: Reload Window - 想确保每次都在新窗口打开项目？别用
-r，直接code .即可（默认行为） - 多人协作调试时，
code -r /path/to/project能避免开一堆窗口，但要注意：如果当前已有窗口打开了同一文件夹，它会把焦点切过去，而不是合并工作区
code --goto 在调试和快速跳转中的真实用法
code --goto 是精准定位的利器，格式是 code --goto <file>:<line>:<column>，但很多人只记得 :line，漏掉 :column 导致光标停在行首而非具体变量位置。
它常被构建工具、测试框架或错误日志调用。比如 Jest 报错时显示 MyTest.spec.ts:42:15，你复制这一段，粘贴进终端：code --goto MyTest.spec.ts:42:15，VSCode 就会直接打开文件并把光标定位到第 42 行第 15 列。
- 文件路径支持相对路径，但必须相对于当前终端工作目录（不是 VSCode 工作区根目录）
- 如果文件未在当前工作区打开，
--goto仍会打开它 —— 这点比单纯双击文件更可靠 - 注意空格：
code --goto "src/utils.ts:100"中引号仅用于防止 shell 解析空格，路径本身不含空格时不需要
code --disable-extensions 启动时禁用扩展的必要性
当你遇到 VSCode 启动卡死、编辑器无响应、或某次保存后自动格式化失效，第一反应不该是重装，而是用 code --disable-extensions 启动一个“纯净环境”验证是否为扩展冲突所致。
这个参数不会卸载或禁用任何扩展，只是本次启动不加载它们 —— 类似浏览器的无痕模式。如果禁用后一切正常，再逐个启用扩展排查即可。
- 配合
--user-data-dir可进一步隔离：比如code --disable-extensions --user-data-dir=/tmp/vscode-test，完全绕过你原有的设置、缓存、历史记录 - 某些扩展（如 ESLint、Prettier、GitLens）在大型仓库中会显著拖慢启动速度，用此参数能快速确认是否是它们导致的延迟
- CI 环境或自动化脚本中，也常用
--disable-extensions避免非预期行为干扰
复杂点在于：有些问题只在特定扩展组合下出现，单个禁用可能测不出来。真要深挖，得配合 code --log 查日志，但多数日常卡顿，--disable-extensions 已经够用了。
