vs code 调试 meteor 全栈应用需手动配置 launch.json，因 meteor 通过 cli 启动复合进程，非普通 express 应用；必须设两个独立配置（node 服务启动 + chrome 连接）及 compound 控制顺序，并满足项目结构、断点位置、source map 等硬性前提。
VS Code 能直接调试 Meteor 全栈应用，但必须手动配置 launch.json，否则 Chrome 断点不触发、Node 断点不命中、meteor 命令无法被调试器接管——这是最常卡住新手的三连坑。
为什么不能直接用默认 Node 或 Chrome 配置
Meteor 不是普通 Express 应用，它通过 meteor CLI 启动一个封装了 Node + Web 服务的复合进程。默认的 "type": "node" 配置会尝试直接运行 JS 文件，而 Meteor 的入口是 CLI 命令；同样，Chrome 调试器若未正确设置 webRoot 和启动时机，就无法与 Meteor 自动注入的 source map 对齐。
-
meteor启动后才加载客户端代码，所以 Chrome 必须等 Node 服务 ready 后再打开 - 服务端断点只能打在
imports/或server/下的文件里，main.js顶层代码基本不可断（Meteor 会先执行初始化逻辑） - 如果
webRoot指向错误（比如写成"${workspaceFolder}/client"），Chrome 调试器找不到源码映射，断点变空心圆
launch.json 必须包含两个独立配置 + 一个 compound
单个配置无法覆盖全栈场景。你得明确区分「谁启动服务」和「谁连接浏览器」，再用 compounds 控制执行顺序：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
"Meteor: Node"：用npm作为runtimeExecutable，传["start"]参数，本质是让 VS Code 执行npm start—— 但前提是你的package.json里有"start": "meteor run"；否则要改成"runtimeExecutable": "meteor"并确保系统 PATH 里能调到它 -
"Meteor: Chrome"：url必须是"http://localhost:3000"（Meteor 默认端口），webRoot必须是"${workspaceFolder}"，不能加斜杠或子路径 -
"Meteor: All"：compound 名称要和两个子配置 name 完全一致，且顺序必须是["Meteor: Node", "Meteor: Chrome"]—— 反过来会导致 Chrome 在服务没起来时就报net::ERR_CONNECTION_REFUSED
调试时容易忽略的三个硬性前提
即使 launch.json 写对了，以下任一条件不满足，断点依然无效：
- Meteor 项目必须用
meteor create初始化，或至少包含.meteor/目录；纯npm init+ 手动装meteor-node-stubs的项目不支持原生调试 - 服务端断点只对
imports/api/xxx.js或server/main.js中的函数内有效；if判断外的顶层语句、console.log行、模块导出声明行，几乎无法停住 - 客户端断点需在 Chrome DevTools 的
sources面板里确认是否显示为「webpack:///」前缀的文件；如果看到的是blob:或空白内容，说明 source map 未加载，此时应检查 Meteor 是否启用了METEOR_SETTINGS干扰了构建流程
真正麻烦的不是配置本身，而是 Meteor 的调试链路太长：CLI → Node 进程 → Webpack 构建 → 浏览器加载 → source map 映射。任意一环断开，VS Code 就只会安静地跳过断点，不报错也不提醒。建议第一次调试前，先在终端手动跑一遍 meteor run，确认页面能正常打开、控制台无 source map 报错，再进 VS Code 按 F5。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
