VSCode终端找不到pnpm最常见原因是其内置终端未加载shell初始化文件，导致PATH缺失pnpm路径；需确认全局安装、将shim或bin路径加入shell配置（如~/.zshrc或$PROFILE）、重启VSCode，并在tasks.json中显式写"pnpm"而非依赖alias。
VSCode终端里找不到pnpm命令
最常见的情况是：你在系统终端（如Windows Terminal、iTerm）能运行pnpm，但在VSCode内置终端里执行就报command not found: pnpm。这不是VSCode的问题，而是它的终端没加载你Shell的环境变量（比如PATH中包含pnpm安装路径）。
解决方法取决于你的Shell和安装方式：
- 如果用
npm install -g pnpm安装，确认全局bin路径已加入Shell配置（如~/.zshrc或~/.bash_profile），然后在VSCode里重启终端（快捷键Ctrl+Shift+`关闭再打开） - 如果用
corepack enable启用pnpm（推荐方式），需确保VSCode终端启动的是登录Shell（macOS/Linux默认不是）。可在VSCode设置里搜terminal.integrated.defaultProfile，把profile设为带-l参数的Shell，例如：/bin/zsh -l - Windows用户若用
npm install -g pnpm，检查%APPDATA%\npm是否在系统PATH中，并确认VSCode没以“精简环境”模式启动（比如从开始菜单快捷方式可能被限制）
运行pnpm run dev但Node.js没起来
命令执行后立刻退出、无报错、端口没监听——大概率是package.json里的scripts.dev没正确指向Node.js入口，或者用了不兼容的包管理器语法。
检查点：
- 确认
scripts.dev值是类似"node index.js"或"ts-node src/index.ts"，而不是只写"index.js"（这会被当成shell命令执行，而非Node.js脚本） - 如果你用
pnpm的exec特性（如pnpm exec ts-node src/index.ts），注意exec会查找node_modules/.bin下的二进制，但不会自动加node前缀；而pnpm run会自动处理 - 某些框架（如Vite、Next.js）的
dev脚本依赖process.env.NODE_ENV，而VSCode终端可能没继承该变量。可临时加前缀：NODE_ENV=development pnpm run dev（macOS/Linux）或set NODE_ENV=development && pnpm run dev（Windows CMD）
pnpm与npm/yarn在VSCode终端的行为差异
VSCode终端本身不区分包管理器，但pnpm的硬链接机制会影响你对node_modules的调试体验：
-
pnpm的node_modules是符号链接+硬链接结构，你在VSCode资源管理器里点开某个依赖，看到的可能是node_modules/.pnpm/xxx/node_modules/xxx路径，而不是平铺结构。这不影响运行，但断点跳转可能失效——建议在launch.json里配resolveSourceMapLocations或直接用pnpm run --inspect -
pnpm默认启用strict-peer-dependencies，如果依赖树里有未满足的peer dep，pnpm install会失败；而npm通常只警告。VSCode终端里看到安装中断，先看错误信息里有没有peer dep关键词 -
pnpm的run命令默认不继承父进程的env（比如你终端里手动export FOO=bar后运行pnpm run dev，FOO不可见），要用pnpm run --env FOO=bar dev显式传入
VSCode调试Node.js时pnpm脚本无法attach
点击“运行并调试”后提示Cannot connect to runtime process，或断点不命中，往往是因为VSCode的launch.json没匹配pnpm启动的实际进程。
关键操作：
- 不要用
node直接启动，而是用pnpm run触发——在launch.json中设"runtimeExecutable": "pnpm"，"runtimeArgs": ["run", "dev"]，并确保"console": "integratedTerminal" - 如果脚本里用了
esbuild、vite等会fork子进程的工具，需加--inspect-brk参数并配autoAttachChildProcesses: true -
pnpm8+ 默认启用enableTransparentWorkspaces，可能导致工作区路径解析异常。遇到Cannot find module类错误，可临时在项目根目录加.pnpm-debug.yaml关掉它
pnpm本身不复杂，真正卡住的往往是环境变量加载时机、node_modules链接结构对调试链路的影响，以及pnpm比npm更严格的依赖校验逻辑——这些细节不报错，但会让行为“看起来不对”。 
