VSCode 本身不提供 Node.js 文件实时监听能力，所有“保存即执行”或“改动即重启”都需依赖外部工具如 nodemon；它通过文件系统事件实现可靠监听与自动重启，优于原生 fs.watch 或编辑器保存事件。
VSCode 本身不提供 Node.js 文件实时监听能力，所有“保存即执行”或“改动即重启”都得靠外部工具介入——nodemon 是最直接、最稳定的选择，尤其适合本地开发调试。
用 nodemon 启动并监听 Node.js 入口文件
这是最常用也最不容易出错的方式：让 nodemon 管理整个监听和重启流程，VSCode 只负责启动它。
- 项目内安装：
npm install --save-dev nodemon（推荐，避免全局污染） - 入口文件假设为
server.js，直接在终端运行：nodemon server.js - VSCode 中可通过
tasks.json封装成任务，方便一键启动：
{
"version": "2.0.0",
"tasks": [{
"label": "start:dev",
"type": "shell",
"command": "npx nodemon server.js",
"group": "build",
"isBackground": true,
"problemMatcher": []
}]
}
注意：problemMatcher 必须为空或删掉，否则任务会卡在“正在运行”状态；isBackground: true 是为了让 VSCode 把它识别为长期运行任务。
自定义监听范围与忽略规则
nodemon 默认监听当前目录下所有 .js、.mjs、.json 文件，但实际开发中常需排除测试或构建产物目录。
- 新建
nodemon.json（与package.json同级）：
{
"watch": ["src", "config"],
"ext": "js,json,ts",
"ignore": ["src/**/*.spec.js", "dist/**/*", "node_modules/**/*"],
"exec": "ts-node src/server.ts"
}
其中 exec 字段决定实际执行命令，搭配 ts-node 可直接跑 TypeScript；ext 必须显式列出扩展名，不能写 js,ts 以外的通配符。
Windows 用户若遇到路径空格报错，确保 exec 值用双引号包裹，例如："exec": "ts-node \"src/server.ts\""。
为什么不用 fs.watch 或 fs.watchFile 自己写监听？
Node 原生的 fs.watch 和 fs.watchFile 在 VSCode 场景下几乎不可靠：
-
fs.watch在 macOS/Linux 下可能丢失事件，在 Windows 下对重命名/移动操作响应不稳定 -
fs.watchFile是轮询机制，默认每 5007ms 检查一次，既耗 CPU 又有延迟，且无法区分“内容修改”和“属性变更” - 两者都不处理子目录递归监听、符号链接、大文件写入中途事件等边界情况
- VSCode 的编辑器保存行为不保证触发原生监听（尤其开启保存时格式化后），容易漏触发
真正需要底层控制时，应优先考虑 chokidar（nodemon 内部就用它），而不是裸用 Node API。
vscode 自带的保存事件监听只响应编辑器内保存
像 Auto Run Command 这类扩展监听的是 onDidSaveTextDocument，它只在你手动 Ctrl+S 时触发，对以下情况完全无反应：
-
git checkout切换分支 - 其他编辑器（如 Vim、Sublime）保存同一文件
- 脚本生成文件（如
swagger-codegen输出 API client） - Docker 容器内写入日志或配置文件
如果你的 workflow 依赖这些外部变更，就必须用 watchexec 或 nodemon 这类基于文件系统事件的工具，而非编辑器事件。
真正麻烦的不是怎么配，而是搞清监听源头——是“人点了保存”，还是“文件系统变了”。前者简单，后者必须绕过 VSCode 事件层。
