require第三方模块时,node.js优先在当前模块同级node_modules中查找,读取package.json的main字段指定入口;无main则默认加载index.js;未找到则向上级目录递归搜索node_modules,直至磁盘根路径,否则报“cannot find module”错误。

能直接 require 或 import 第三方包,且 node_modules 不报红、不提示“Cannot find module”,才算依赖真正导入成功——不是装了就完事,关键在路径、解析规则和 VSCode 的感知是否一致。
npm install 后模块仍标红或报 Cannot find module
VSCode 本身不参与模块安装,它只读取 node_modules 目录结构并按 Node.js 解析逻辑做静态分析。标红往往不是代码错,而是环境没对齐。
- 确认当前打开的是项目根目录(含
package.json),不是子文件夹——VSCode 的 JS/TS 语言服务依赖根目录下的node_modules和package.json判断模块可用性 - 检查
package.json中是否真有该依赖:运行npm list <pkg-name></pkg-name>,若输出空或empty,说明没装进当前项目(比如误在父目录执行了npm install) - Windows 用户注意:如果项目路径含中文或空格(如
D:\我的项目\nodejs-app),node_modules内部符号链接可能损坏,导致 VSCode 无法遍历,重装依赖前先挪到纯英文无空格路径 - 装完后没重启 VSCode —— TypeScript 语言服务缓存未刷新,标红不会自动消失;关掉所有窗口再重开,或按
Ctrl+Shift+P→ 输入Developer: Restart Language Server
ES Module 场景下 import 报错:Cannot use import statement outside a module
这是 Node.js 运行时层面的解析错误,VSCode 只是提前预警。根本原因是文件没被识别为 ES 模块,而非导入语法本身有问题。
使用 JSON Schema 验证 JSON 数据,从示例 JSON 生成 schema,并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 优先检查项目根目录
package.json是否含"type": "module"—— 没这行,Node.js 默认按 CommonJS 解析.js文件,import会直接崩溃 - 若不想改
package.json,可把文件扩展名改成.mjs,Node.js 遇到该后缀强制启用 ES Module 模式 - VSCode 内置终端执行
node index.js报这个错,说明不是编辑器问题,而是运行配置没对;别依赖 Code Runner 插件跑,它常忽略package.json的type字段 - 用
import加载本地文件时,路径必须带扩展名(import { foo } from './utils.js'),CommonJS 的require('./utils')可省略,但 ES Module 不行
调试时断点进不到 node_modules 里的依赖源码
VSCode 默认不加载 node_modules 中的源映射(source map),即使你装的是带 sourceMappingURL 的包,也不会自动跳转。
- 想单步进依赖源码,需在
.vscode/launch.json的配置里加"resolveSourceMapLocations": ["!**/node_modules/**"]—— 注意是 去掉 开头的!才启用,即:"resolveSourceMapLocations": ["**/node_modules/**"] - 但绝大多数 npm 包发布的都是编译后代码(无原始 TS/ES6),即使开了 source map,看到的仍是压缩或转译后的逻辑,非原始可读源码
- 真正可靠的调试方式是:用
npm link或yarn link把本地开发中的依赖包软链接进来,VSCode 能完整索引其源码,断点、跳转、hover 类型都正常 - 别指望
node_modules里的包自带完整调试支持——它们面向运行,不是开发;需要深度调试时,应优先查文档、写单元测试,或直接 fork 修改
最易被忽略的点:VSCode 对 node_modules 的感知完全依赖文件系统实际状态,而不是 package.json 的声明。删了 node_modules 却没重装,或用了 npx 临时执行命令,VSCode 都会“看不见”那些模块——它不猜,只读。










