CLI工具断点调试失败主因是未用"launch"模式、program路径错误或调试器type不匹配；必须明确指定可执行入口、正确type值及args/cwd等参数，否则VSCode无法启动进程或命中断点。
CLI 工具断点调试失败，90% 是因为没走 launch 模式、program 路径不对、或调试器类型不匹配——VSCode 不会自动猜你要调试的是哪个二进制，必须明确告诉它“用什么运行、从哪启动、带什么参数”。
CLI 调试必须用 request: "launch"，不是 "attach"
绝大多数 CLI 工具（如 spicetify、vite、eslint 本地封装脚本）是直接执行的可运行入口，不是后台常驻进程。所以 launch.json 中 request 字段必须是 "launch"，设成 "attach" 会导致调试器干等端口、永远不启动进程。
-
"request": "launch"：VSCode 自己拉起进程，控制生命周期，支持args、env、cwd等完整配置 -
"request": "attach"：只用于已运行的服务（如npm run dev启动的 Vite），需提前暴露调试端口（如--inspect=9229） - 常见错误：把
spicetify apply配成attach，结果调试器报connection refused，其实根本没进程在监听
program 必须指向可执行入口，不是 package.json script
VSCode 不解析 npm run xxx，它只认真实文件路径。如果你的 CLI 是 Go 写的（如 spicetify），program 应该是 "${workspaceFolder}/spicetify.go" 或编译后的二进制（如 "${workspaceFolder}/bin/spicetify"）；如果是 Node.js CLI（如本地 cli.js），就写 "${workspaceFolder}/src/cli.js"。
- 别写
"program": "npm"或"program": "yarn"—— 这会让调试器试图把 npm 当成被调程序，而不是工具 - Node.js CLI 若用 ESM，必须加
"runtimeArgs": ["--loader", "ts-node/esm"]，否则import报错且断点不加载 - Python CLI 推荐用
"module"而非"program"，例如"module": "mytool.cli"（对应python -m mytool.cli），避免路径和sys.path错乱
语言类型 type 和插件必须严格对应
launch.json 的 type 字段不是随便写的标签，它决定了 VSCode 加载哪个调试扩展、调用哪套协议。写错就等于让快递员把包裹送到隔壁省。
- Go CLI：必须是
"type": "go"，且已安装官方Go扩展；"go"不能写成"Go"或"golang" - Node.js CLI：用
"type": "pwa-node"（新版 js-debug 默认）或"node"（旧版）；"pwa-chrome"是浏览器调试用的，不适用 CLI - Python CLI：用
"type": "python"，不是"debugpy"（那是扩展名，不是 type 值） - 没装对应扩展时，VSCode 会直接报
Can't find a debug adapter for 'xxx'，此时别改配置，先装扩展
参数和工作目录错一位，断点就停不到正确位置
args 和 cwd 看似次要，实则决定 CLI 是否能读到配置文件、是否能找到子命令、甚至影响 sourceMap 加载路径。
-
args是字符串数组，不是拼接字符串："args": ["apply", "--force"]✅，"args": ["apply --force"]❌（后者会被当做一个参数传给主函数） -
cwd影响相对路径解析：CLI 若默认读./spicetify.conf，但cwd设成"${workspaceFolder}/src"，就会找不到配置文件，提前 panic 退出，断点根本没机会触发 - TypeScript CLI 必须确保
tsconfig.json中"sourceMap": true且"inlineSourceMap": false，否则断点打在.ts文件上，却停在编译后.js的某一行偏移处
最易被忽略的一点：CLI 往往有子进程（比如 spicetify apply 会 fork 出 sed 或 cp），而默认调试器只跟踪主进程。如果关键逻辑在子进程里（如 Git 操作、模板渲染），必须显式开启 "subProcess": true（Python/Node.js 支持），否则断点永远进不去。
