软连接循环导致 node 启动卡死或崩溃的典型表现是进程长时间无响应、cpu 占用飙高但无输出；npm run 命令卡住且 ctrl+c 无效；vscode 终端中 which node 正常但 node --version 挂起后报错或退出，根源在于 node.js 在 fs.realpathsync() 阶段因符号链接双向指向陷入路径遍历死循环。
软连接循环导致 Node 启动卡死或崩溃的典型表现
执行 node 或通过 VSCode 调试器启动时，进程长时间无响应、CPU 占用飙高但无输出；npm run 命令直接卡住，Ctrl+C 无效；VSCode 的终端里 which node 正常，但 node --version 挂起数秒后报错或退出。这不是插件问题，而是 Node.js 在解析 require() 或加载 node_modules 时陷入路径遍历死循环——尤其常见于使用 ln -s 手动构建符号链接树、或某些 monorepo 工具（如 pnpm link、yalc）残留的跨目录软链。
用 find + ls -la 快速定位循环软链
Node 不会主动报“循环链接”，它只是在 fs.realpathSync() 阶段反复跳转、超时后静默失败。你得手动检查项目根目录及 node_modules 下可疑路径：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 运行
find . -type l -ls | head -20，看是否有类似./packages/core -> ../core→../core -> ./packages/core这种双向指向 - 对报错中出现的模块路径（比如
node_modules/foo/node_modules/bar）逐级ls -la，重点观察->后的路径是否最终又指回自身或父级node_modules - 特别注意
node_modules/.bin里的可执行文件：它们常是软链到对应包的bin/index.js，若该包又被软链进当前项目，就极易形成闭环
VSCode 中如何绕过软链触发点验证问题
别依赖 “重启 VSCode” 或 “禁用插件” —— 这类崩溃发生在 Node 子进程启动阶段，和 VSCode 主进程无关。真正有效的验证方式是隔离 Node 加载行为：
- 在终端中直接运行
node --max-old-space-size=2048 -e "console.log('ok')"：如果卡住，说明环境层（如 shell 的PATH或node二进制本身）已被污染 - 用绝对路径调用 Node：
/usr/local/bin/node --version（macOS/Linux）或C:\Program Files\nodejs\node.exe --version（Windows），排除软链版node的干扰 - 在
launch.json中显式指定"runtimeExecutable"，例如："runtimeExecutable": "/usr/local/bin/node"，避免调试器自动调用被软链污染的node
修复时最容易忽略的三个点
删掉一个软链不等于解决问题。循环往往藏在多层嵌套里，且某些工具会自动生成新链：
-
pnpm的pnpm link和pnpm unlink不会自动清理node_modules/.pnpm下的硬链引用，必须手动pnpm store prune - VSCode 的 JavaScript 语言服务（如 TypeScript Server）会缓存
node_modules路径，即使你删了软链，重启编辑器前要先执行Developer: Restart TS Server - 某些 IDE 插件（如 ESLint、Import Sorter）会在后台预扫描
node_modules，它们的缓存路径（如.eslintcache或.importsorter）可能仍持有旧链接，需一并删除
