根本原因是source map映射链断裂：tsconfig.json未设"sourcemap": true，launch.json中"outfiles"路径与编译输出不一致，或"resolvesourcemaplocations"未覆盖ts源码路径。
断点打在 src/index.ts 上，却停在 dist/index.js 的错误行号——这不是 VS Code 坏了，是 source map 映射链断在了某个环节。核心问题从来不是“要不要开 sourceMap”，而是“VS Code 能不能从 JS 行号精准回溯到 TS 源码的哪一行、哪个文件”。
sourceMap 文件必须存在且路径可访问
VS Code 不会生成 .map 文件，它只读取构建产物里已有的 .js.map。如果 tsc 没输出它，调试器就彻底失明。
-
tsconfig.json中必须有"sourceMap": true，且"inlineSourceMap": false（VS Code 优先读独立 .map 文件，inlineSourceMap容易导致解析失败或行号偏移） - 编译后检查
dist/目录下是否存在同名.js.map文件，比如dist/index.js对应dist/index.js.map - 如果用
webpack或vite构建，确认其devtool或build.sourcemap选项已启用，并输出到正确位置
launch.json 中的 outFiles 必须匹配实际输出路径
outFiles 不是“建议路径”，而是调试器扫描 JS 文件的唯一入口。写错一个字符，source map 就加载失败。
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 值必须是数组，例如：
"outFiles": ["${workspaceFolder}/dist/**/*.js"] - 路径要和你实际构建输出完全一致：若构建到
lib/，就不能写dist/；若用tsup输出到build/，就得改成"${workspaceFolder}/build/**/*.js" - 通配符
**是必须的，否则子目录下的文件（如dist/router/index.js）会被忽略
resolveSourceMapLocations 控制源码定位范围
即使 .map 文件存在、outFiles 也对，VS Code 还得知道“哪些 TS 文件是可信的源”。默认它会跳过 node_modules 和非工作区路径，但多包项目常踩这个坑。
- 如果你的 TS 源码不在
src/下（比如在packages/core/src），必须显式放行："resolveSourceMapLocations": ["${workspaceFolder}/packages/**/src/**", "!**/node_modules/**"] - 路径模式支持
!排除，顺序重要：先写允许路径，再写排除项 - 如果不确定范围，可临时设为
["${workspaceFolder}/**"]测试，验证后再收紧
调试控制台里看 Loaded source map from: 才算真正生效
光看断点变实心红圈不保险。打开「调试控制台」（Debug Console），搜索 Loaded source map from: —— 这才是 source map 加载成功的唯一证据。
- 出现
404：说明outFiles路径没扫到 JS，或 .map 文件根本不存在 - 出现路径但行号仍错位：大概率是构建时用了
inlineSourceMap或sourceRoot设置错误，导致映射坐标偏移 - 完全没这条日志：检查
"sourceMaps": true是否漏写，或配置被其他字段（如skipFiles）意外屏蔽
最常被忽略的是：source map 生效依赖构建工具与调试器两套路径逻辑的严格对齐。哪怕 tsconfig.json 和 launch.json 都配对了，只要构建时输出目录和 outFiles 差一个斜杠，断点就会永远错位。
