sublime text 无法原生调试 node.js，必须通过终端执行 node --inspect-brk 启动进程，并在 chrome 的 chrome://inspect 中手动连接；构建系统仅支持运行，不支持调试功能，因其不解析 v8 inspector 协议、无法监听 websocket 或接管调试会话。
Sublime Text 本身不提供包管理器（如 npm、pnpm、yarn）的集成调试能力，它只是编辑器；所谓“调试本地 Node 包管理工具”，实际是指：在 Sublime 中编辑 package.json 或脚本后，能快速运行/调试 npm 脚本（比如 npm run dev）、或调试你本地开发的 CLI 工具（如用 npm link 链入的包）。关键不是让 Sublime “管理包”，而是让它可靠地启动带调试参数的 Node 进程。
为什么直接写 npm run debug 到构建系统里会失败
常见现象是：Ctrl+B 后输出一堆日志就退出，断点不生效，chrome://inspect 列表里找不到目标进程。根本原因有三个：
-
npm run启动的是 shell 子进程，Sublime 的 Build System 只捕获 stdout/stderr，无法透传 V8 Inspector 的 WebSocket 地址，更不会等待调试器连接 - 很多
npm scripts（如"dev": "node --inspect-brk server.js"）本身已含--inspect-brk，但 Sublime 不解析命令行参数语义，只当普通字符串执行 - Windows 下
cmd /c npm run xxx和 macOS/Linux 的sh -c行为不一致，容易导致路径解析失败或信号丢失
npm link 开发的 CLI 工具怎么在 Sublime 里调试
你用 npm link 把本地包链接到全局，然后在项目里执行 my-cli --help —— 这时想断点进 CLI 源码，不能靠 node my-cli.js 直接运行（因为入口是 npm 生成的 wrapper 脚本）。正确做法是：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 找到真实入口：运行
which my-cli（macOS/Linux）或where my-cli（Windows），通常指向类似/usr/local/bin/my-cli，它本质是个 symlink，用ls -l查到真实路径，比如/path/to/your/cli/src/bin.js - 手动启动调试：终端中执行
node --inspect-brk /path/to/your/cli/src/bin.js --help（注意把参数放在--inspect-brk后面） - 别用构建系统跑这个：Sublime 的
$file是当前编辑文件，不是 CLI 入口；硬塞进构建系统会导致路径错乱或权限拒绝
构建系统里安全调用 npm 的唯一方式
如果你坚持要用 Ctrl+B 触发 npm 命令（仅限非调试场景，比如跑测试、格式化），必须绕过 shell 解析陷阱：
- 不要设
"shell": true—— GUI 启动的 Sublime 不加载你的~/.zshrc或PATH，npm很可能找不到 - 用绝对路径：先运行
which npm，得到类似/opt/homebrew/bin/npm，构建文件里写成["/opt/homebrew/bin/npm", "run", "test"] - 加
"working_dir": "$file_path"，否则npm run build里require('./dist')会报Cannot find module - 避免在
cmd数组里拼接字符串：像["npm run dev"]是错的，必须拆成["npm", "run", "dev"]
真正要调试，就得离开 Sublime 的构建系统——它连进程生命周期都管不住，更别说调试会话状态。最简路径永远是：改完代码 → 终端 Ctrl+C 停旧进程 → node --inspect-brk xxx.js → Chrome 里点 Open dedicated DevTools for Node。任何试图让 Sublime “接管调试”的插件，底层仍是调用这个流程，只是多了一层封装，反而增加故障点。
