根本原因是windows未将node.exe路径加入path环境变量，需手动添加c:\program files\nodejs\及npm全局bin路径（如%appdata%\npm\node_modules.bin）到系统path，并重启终端验证。
node -v 命令报错：不是内部或外部命令
根本原因是 Windows 没把 node.exe 所在路径加进系统 PATH 环境变量。哪怕安装时勾选了 “Add to PATH”，某些杀毒软件、组策略或旧版安装器仍可能跳过这步。
- 打开命令行，执行
where node—— 如果返回空，说明系统完全找不到node.exe - 手动定位：通常在
C:\Program Files\nodejs\或C:\Users\{用户名}\AppData\Roaming\nvm\（若用了 nvm） - 把该路径复制下来，进入「系统属性 → 高级 → 环境变量」→ 在「系统变量」中找到
Path→ 点击「编辑」→ 「新建」→ 粘贴路径 → 保存 - 重启所有已打开的终端（包括 VS Code 内置终端），再试
node -v
别信“重装一遍就行”——重装不解决 PATH 漏写问题，反而可能叠加多个重复路径，导致后续 npm 找包混乱。
npm install -g express 后，全局命令 express 仍不可用
这不是 Express 安装失败，而是 npm 全局模块的 bin 目录没进 PATH。LTS 版 Node.js 默认把全局包装到 %APPDATA%\npm（Windows）或 ~/npm（macOS/Linux），这个路径和 node.exe 不在同一个目录下，必须单独添加。
- 先查真实路径：终端运行
npm config get prefix，输出就是全局安装根目录 - Windows 下，该路径下的
node_modules\.bin才是全局可执行文件所在位置，例如：%APPDATA%\npm\node_modules\.bin - 把这个
.bin路径追加进系统Path变量（不是 prefix 根目录！） - 验证：关闭所有终端，新开一个，运行
express --version
很多人卡在这里，是因为只加了 prefix 路径，却忽略了 .bin 子目录 —— 这是 npm 的设计，不是 bug。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
VS Code 调试时断点不命中，或提示“无法连接到目标”
VS Code 自带 Node.js 调试器，但默认不启用源码映射（source map）支持，也不自动识别 package.json 中的 type: "module"。常见于 ESM 项目或用了 TypeScript/Babel 编译的场景。
- 检查当前文件是否被识别为 CommonJS：在 VS Code 底部状态栏看右下角，显示 “JavaScript (CommonJS)” 才能直接调试；若显示 “JavaScript (ES Module)”，需额外配置
- 对 ESM 项目，在
.vscode/launch.json中显式指定运行时参数："runtimeArgs": ["--loader", "ts-node/esm"]（TypeScript）或去掉"type": "module"临时切回 CommonJS 测试 - 确保 launch.json 中的
"program"指向的是实际入口文件（如"${workspaceFolder}/src/index.ts"），而不是编译后的dist/目录 - 禁用所有非必要扩展（尤其是老旧的 “Node Debug” 插件），VS Code 1.80+ 已原生支持 Node.js 20+ 的 ESM 调试，第三方插件反而干扰
断点失效往往不是环境没配好，而是 VS Code 没按你预期的方式加载代码 —— 它只认 launch.json 里写的路径和参数，不猜你的构建意图。
ESLint + Prettier 冲突：保存后格式被反复重写
两者定位不同：ESLint 检查逻辑与风格，Prettier 只管格式。冲突根源在于 ESLint 的 prettier 插件未正确禁用其自带的格式规则，导致两个工具互相覆盖。
- 必须安装
eslint-config-prettier，并在.eslintrc.js的extends数组末尾加上"prettier" - VS Code 设置里关掉
eslint.format.enable（设为false），让 Prettier 独占格式化职责 -
.prettierrc中避免写 ESLint 已覆盖的规则（如semi、quotes），否则容易形成“保存 → Prettier 改 → ESLint 报错 → 自动修 → 再改”的死循环 - 推荐组合：ESLint（含
eslint-plugin-import、@typescript-eslint）做质量检查，Prettier 做格式统一，分工明确才稳定
格式化冲突表面是配置问题，本质是没厘清工具边界 —— 把 Prettier 当成 ESLint 的子集来用，迟早踩坑。
