code . 默认以前台进程运行，会阻塞终端直至 VSCode 关闭；要立即返回控制权，需加 &（Linux/macOS）或 start code .（Windows），或使用 nohup code . >/dev/null 2>&1 & 跨平台后台启动。
直接在系统终端里输入 code . 就能启动 VSCode 并打开当前目录为工作区——但很多人输完回车，VSCode 打开了，终端却卡住、不返回控制权，或者后续命令无法执行。这不是 bug，是默认行为；真正要用好，得理解它怎么“交还终端”。
为什么 code . 后终端会卡住？
VSCode 的 code 命令默认是前台进程：它会阻塞当前终端，直到 VSCode 窗口被手动关闭。这跟 vim 或 git gui 类似，属于“调用即接管终端”的设计。
- 你看到光标不动、不能输新命令，是因为 shell 在等
code进程退出 - 关掉 VSCode 窗口后，终端才恢复可用
- 这不是安装问题，也不是 PATH 错误，是 CLI 的默认交互模式
让终端立刻返回控制权的两种可靠写法
想启动 VSCode 同时继续用终端？必须显式告诉 shell “别等它”：
- Linux/macOS：
code . &（末尾加空格 +&） - Windows（CMD/PowerShell）：
start code .（注意不是start /B，后者不适用于code命令） - 更通用且跨平台的写法：
nohup code . >/dev/null 2>&1 &（适合脚本中调用，避免输出干扰）
⚠️ 不要写 code . &（HTML 实体），必须是纯文本 &；也不要依赖 ctrl+z + bg，那只是临时补救，不可靠。
code --new-window . 比 code . 多解决什么？
多数人只关心“能不能启动”，但真正影响开发流的是环境变量是否完整继承。双击图标或开始菜单启动的 VSCode，不会加载你的 ~/.zshrc 或 ~/.bash_profile；而 code --new-window . 是从已激活的 shell 中发起的，PATH、nvm、pyenv、自定义 alias 全部可用。
- 执行前先确认当前终端能跑
npm -v或python3 --version - 如果这些命令正常，但 VSCode 内置终端里报
command not found，大概率就是没走--new-window - Windows 用户若用 WSL，必须在 WSL 终端里运行
code .，否则调用的是 Windows 版 VSCode，PATH 和端口都错位
终端启动失败的三个典型信号
如果 code . 执行后无反应、报错或弹窗一闪而逝，先看这几处：
-
command not found: code→ 安装时没勾选“Add to PATH”，需重装或手动添加 VSCode 的 bin 目录到系统 PATH - 空白窗口 / 卡在白屏 → VSCode 正在加载扩展，可加
--disable-extensions快速验证是否插件冲突 - 报错
Failed to launch browser或port already in use→ 不是启动失败，是项目任务（如npm run dev）在 tasks.json 里配置了自动触发，但服务端口被占，和code命令本身无关
真正容易被忽略的是：code 命令本身不读取任何 VSCode 设置文件（如 settings.json），它只负责拉起进程；所有编辑器级行为（比如终端默认 shell、工作区路径）都是 VSCode 主进程启动后才加载的。
