vscode不配置包管理器，而是确保终端、tasks、ts server等各子系统正确调用已安装的pnpm/yarn/npm：终端需加载shell配置以更新path；tasks.json须显式写"command":"pnpm"；ts server需重启并检查.pnpm结构；调试应使用pnpm exec避免wrapper干扰。
VSCode 本身不“配置包管理器”，它只是调用你系统里已安装的 npm、yarn 或 pnpm。所谓“配置”，本质是让终端、任务、调试等场景能正确找到并执行对应命令，同时避免因环境隔离或路径缺失导致报错。
终端里 npm/yarn/pnpm 命令找不到
这不是 VSCode 设置问题，而是终端没加载你的 shell 初始化文件（如 ~/.zshrc、$PROFILE），导致 PATH 里没有这些命令的路径。
- 先在系统终端（非 VSCode）里运行
which npm或where yarn，确认它们确实装好了 - macOS/Linux：检查
~/.zshrc或~/.bash_profile是否包含export PATH=...把 Node.js bin 目录加进去了 - Windows PowerShell：确保
$PROFILE里有Set-Alias -Name npm -Value pnpm（仅用于别名），但更推荐把pnpmbin目录加进系统 PATH - VSCode 启动方式影响环境：从 Dock 或开始菜单打开，常拿不到 shell 环境；改用命令行执行
code .才能继承完整 PATH
tasks.json 里跑的是 npm 而不是 pnpm
VSCode 的任务系统完全不读取 shell alias 或 profile，npm 在 tasks.json 里就是字面意思——它会去 PATH 里找名为 npm 的可执行文件，不会自动替换成 pnpm。
- 必须显式写
"command": "pnpm"，不能依赖别名 - 如果项目用了
corepack，确保已执行corepack enable，且package.json中packageManager字段声明了版本，例如"pnpm@8.15.0" - 旧版
tasks.json若硬编码了npm install，删掉重生成：Cmd/Ctrl+Shift+P →Tasks: Configure Task→Create tasks from package.json
TypeScript 智能提示找不到 pnpm 安装的包
这和终端无关，是 TS Server 没正确解析 node_modules/.pnpm 下的硬链接结构，常见于跳转失败、import 报红但实际能运行。
- 先确认
node_modules/.pnpm存在且非空；若不存在，可能是.npmrc里engine-strict=true拦截了安装 - VSCode 设置中关闭
typescript.preferences.includePackageJsonAutoImports，它会错误地从package.json推导依赖，绕过 pnpm 的符号链接逻辑 - 修改 tsconfig.json 后或切换包管理器后，务必重启 TS Server：Cmd/Ctrl+Shift+P →
TypeScript: Restart TS server
调试时 exec 脚本仍走 npm wrapper
比如你配了 pnpm exec jest，但在 launch.json 里直接写 "program": "node_modules/.bin/jest"，可能触发 npm 的 wrapper 脚本而非真实二进制，导致调试断点失效或环境变量丢失。
- 调试脚本应统一走
pnpm exec入口，例如"program": "${workspaceFolder}/node_modules/.pnpm/jest@29.7.0/node_modules/jest/bin/jest.js"不可靠 - 更稳妥做法：在
launch.json中用"runtimeExecutable": "pnpm"+"runtimeArgs": ["exec", "jest"] - 避免混用包管理器：同一项目里
npm install和pnpm install交替执行，会导致node_modules结构混乱，TS 和调试都可能出问题
真正容易被忽略的点是：VSCode 的各个子系统（终端、tasks、debug、TS Server）彼此隔离，改了一个地方，其他地方未必同步生效。比如你在 shell 里 alias 了 npm，终端能用，但 task 和 debug 依然认原始命令——这不是 bug，是设计如此。
