Node.js运行时未扫描到模块，主因是工作目录非项目根、模块未实际安装或CommonJS/ESM路径规则混淆；需用pwd验证目录、npm ls查依赖、require.resolve()测路径，并区分终端与调试器环境。
VSCode终端能运行 node -v，但执行脚本时提示 Cannot find module，说明 Node.js 运行时根本没扫描到目标模块——不是代码写错了，而是模块路径、工作目录或环境变量没对上。
确认当前工作目录是否为项目根目录
Node.js 查找 node_modules 和相对路径（如 require('./utils')）时，起点是当前工作目录（process.cwd()），不是你打开的 JS 文件所在位置，也不是 VSCode 窗口标题显示的路径。
- 在 VSCode 终端里执行
pwd（macOS/Linux）或Get-Location（PowerShell），看输出是否和你项目根目录（含package.json和node_modules的那层）一致 - 如果只打开了
src/子目录，VSCode 默认工作目录就是src/，require('./utils')会去src/utils找，而不是src/../utils - 最稳做法：用终端进入项目根目录后，运行
code .启动 VSCode；不要双击文件夹图标或只打开单个文件
验证模块是否真被安装进 node_modules
npm install 成功不等于模块进了依赖树。VSCode 编辑器里的类型提示、TS Server、甚至 require 都只认实际安装结果，不认 package.json 里写的字。
- 在终端里运行
npm ls（例如npm ls axios），如果返回空或empty，说明它压根没装进去 - 检查
package.json是否写在了错误的字段里：比如你在devDependencies装了jest，但用node index.js运行生产脚本，Node 不会加载devDependencies - 删掉
node_modules和package-lock.json，再跑一次npm install；尤其用了yarn workspaces或pnpm，别混用npm install
区分 CommonJS 和 ESM 的路径规则
同一个 require('./utils') 或 import './utils'，在不同模块系统下行为完全不同。报错不是语法错，是解析逻辑崩了。
- ESM 模式下（
package.json有"type": "module"），import必须带扩展名：import utils from './utils.js'，写成./utils一定报错 - CommonJS 下
require('./utils')会自动尝试.js、.json、.node和index.js，但大小写敏感（Linux/macOS 下Utils.js ≠ utils.js） - 用
node -e "console.log(require.resolve('./utils'))"直接验证路径能否解析成功；报错信息里会列出它实际尝试的所有完整路径，比猜快得多
调试器和终端的 PATH 是两套环境
VSCode 终端能跑 node -v，不代表调试器（F5）也能——调试器启动的是全新进程，完全不继承终端的 PATH 或 shell 配置。
- 如果
launch.json报Cannot find runtime 'node'，别改environment（已弃用），改用env字段显式补全："env": { "PATH": "${env:PATH}:/usr/local/bin" } - Windows 用户注意分隔符是
;，不是:；路径要写对平台键：terminal.integrated.env.windows - 更彻底的做法：在
launch.json里硬编码runtimeExecutable，例如"runtimeExecutable": "C:\nodejs\node.exe"
真正卡住的地方，往往不是“有没有装”，而是“Node 在哪找”——工作目录、模块系统、调试器独立环境，三者只要一个错位，Cannot find module 就会准时出现。验证时少靠感觉，多用 npm ls、require.resolve() 和 echo $PATH 这类直接暴露真相的命令。
