[Bug] npx @deepseek-ai/dsh web 无限卡死：npm 依赖解析死循环（CPU 100%、零网络流量、换镜像无效）

[chriswild1985]

环境

项目	值
OS	Windows 11
Node	v24.16.0
npm	11.17.0
dsh	0.1.0-rc.7（npm latest tag）
registry	npmmirror 与 npmjs.org 均可复现

现象

npx @deepseek-ai/dsh web 无限卡死：

• 零网络流量（不是慢，是完全没有任何下载活动）
• npm 进程单核 CPU 100% 空转，内存持续增长（10 分钟内约 80MB → 700MB）
• 永远不会完成，也不报错
• 清 npm 缓存、切换国内镜像均无效（根因不在网络）

npm install -g @deepseek-ai/dsh 走同一套解析器，同样卡死。

诊断过程

用 npx --loglevel verbose @deepseek-ai/dsh web 复现，观察到：

1. 约 120 个包的元数据请求全部在几百毫秒内正常返回 200（两个源都一样）——网络层完全正常
2. verbose 日志冻结在 Arborist 的 placeDep（依赖摆放/回溯）阶段，之后 10+ 分钟无任何新增输出
3. 进程状态：CPU 累计烧掉 430+ 秒、内存 700MB、网络零流量

日志最后两行（此后再无输出）：

547 silly placeDep ROOT @deepseek-ai/dsh-launch-environment@0.1.0-rc.8 OK for: @deepseek-ai/dsh-app-boot@0.1.0-rc.8 want: ^0.1.0-rc.8
548 silly placeDep ROOT @deepseek-ai/dsh-base@0.1.0-rc.8 OK for: @deepseek-ai/dsh@0.1.0-rc.7 want: ^0.1.0-rc.7

可能的根因

注意上面的版本组合：根包 dsh 解析到 rc.7（latest tag），但它的 ^0.1.0-rc.7 依赖全部解析到了已发布的 rc.8。rc.7 根 + rc.8 子包的混合依赖树，叠加 70+ 个互相以 peer dependency 引用的子包，疑似触发 npm Arborist 解析器的指数级回溯（组合爆炸），导致解析永远无法收敛。

pnpm 解析同一棵树完全没有问题（见下），说明问题出在 npm 解析器与这种依赖结构的组合上。

佐证：pnpm 完全正常

同一台机器上：

pnpm dlx @deepseek-ai/dsh web

512 个包正常解析、下载、安装，dsh 成功启动，http://127.0.0.1:3080 返回 200。

另外：8 月 20 日（rc.8 子包陆续发布前后）npx 还能正常安装运行（本机有成功运行的历史缓存），之后同样命令开始卡死，怀疑是 rc.8 子包发布后依赖树变化引入的回归。

临时规避

pnpm dlx @deepseek-ai/dsh web

建议

1. 排查 latest 指向的 rc.7 与已发布的 rc.8 子包之间的解析问题——统一发版节奏或将 latest 指向配套完整的版本
2. README/文档中补充 pnpm 作为 npm 卡死时的已知规避方案（Windows + npm 用户大概率会踩到）
3. 长期看若能简化 peer dependencies 结构（或收窄版本 range），可降低触发 npm 解析器最坏情况的概率

[DXDEEISEE]

牛逼，刚刚遇见这个问题上网搜就看见你了

[i-nekoo]

我也卡死了，问AI然后它和它测试半天，GPT5.6建议我发过来详细情况：

我在 Windows 上复现了这个问题，并做了一组 A/B 对照测试。目前结果强烈指向 npm 的 peer dependency resolution / Arborist idealTree 阶段，而不是网络、npm cache 或 DSH 实际启动阶段。

环境

• OS: Windows 11, Windows_NT 10.0.26200
• PowerShell: 7.6.5
• Node.js: v24.16.0
• npm: 11.13.0
• DSH: @deepseek-ai/dsh@0.1.0-rc.6
• npm registry: https://registry.npmjs.org/

原始现象

执行：

npx @deepseek-ai/dsh web

或者单独测试：

npm install @deepseek-ai/dsh@0.1.0-rc.6 \
  --package-lock-only \
  --ignore-scripts \
  --no-audit \
  --no-fund \
  --loglevel verbose \
  --timing

均可以复现。

表现为：

1. npm 可以正常连接 registry。
2. 大量依赖 metadata 请求均返回 HTTP 200。
3. 随后 npm 停止产生有意义的输出。
4. node.exe 仍持续占用 CPU。
5. 网络流量基本归零。
6. Node 内存持续增长，测试中曾增长到数 GB。
7. 长时间不结束。
8. Ctrl+C 有时无法正常终止，只能 Stop-Process / Task Manager 强杀。
9. dsh web 本身实际上还没有进入 Web Server 启动阶段，因此 127.0.0.1:3080 不会监听。

已测试并基本排除：

• npm registry 无法访问
• npm cache 损坏
• npx 临时目录损坏
• npm audit / fund
• install scripts
• 单纯下载速度问题

npm ping 正常，npm cache verify 正常，依赖请求也大量返回 HTTP 200。

---

关键 A/B 测试

随后保持所有环境完全相同，只增加：

--legacy-peer-deps

完整测试命令：

npm install @deepseek-ai/dsh@0.1.0-rc.6 \
  --package-lock-only \
  --ignore-scripts \
  --legacy-peer-deps \
  --no-audit \
  --no-fund \
  --loglevel verbose \
  --timing

结果立即从“无限卡死 + 内存持续上涨”变为正常完成：

npm timing idealTree:buildDeps Completed in 24667ms
npm timing idealTree Completed in 24679ms
npm timing reify:loadTrees Completed in 24680ms
npm timing reify Completed in 24792ms

up to date in 25s

npm timing command:install Completed in 24795ms
npm timing npm Completed in 25114ms
npm verbose exit 0
npm info ok

也就是说：

default peer dependency resolver
    -> hangs / memory keeps growing

--legacy-peer-deps
    -> completes successfully in ~25 seconds

由于唯一关键变量是 peer dependency resolution，这似乎可以较强地说明问题发生在 npm Arborist 构造 DSH dependency / peerDependency graph 的过程中。

怀疑方向

仓库中此前已经有人报告过内部 package graph 存在 cyclic peer/workspace dependencies，例如 Cordis 相关包之间的环。

因此怀疑当前 @deepseek-ai/dsh@0.1.0-rc.6 发布包中的大量 peerDependencies / cyclic peer graph，在 npm 11 Arborist 下触发了极端 dependency resolution 行为：

DSH package graph
    ↓
npm Arborist idealTree
    ↓
peer dependency resolution does not converge normally
    ↓
CPU usage + continuously increasing memory
    ↓
apparent infinite hang / eventual possible OOM

--legacy-peer-deps 跳过 peerDependencies 后立即恢复正常，这一点似乎与该假设高度一致。

建议官方检查

建议使用 Windows + Node 24 + npm 11 对发布后的 npm tarball 做 clean-environment smoke test，而不仅仅测试 pnpm workspace。

特别建议测试：

npm install @deepseek-ai/dsh@<version> --package-lock-only

并监控：

• Arborist idealTree duration
• peak RSS / heap usage
• cyclic peerDependencies
• npm 11 resolver behavior

目前 --legacy-peer-deps 可以作为 dependency-resolution 层面的 workaround，但我不建议把它视为最终修复，因为它会跳过 peer dependency contract，也不能保证之后完整 runtime 一定不存在缺失 peer package 的问题。

[chriswild1985]

更新：0.1.1-rc.2 依然卡死，但这次拿到了根因实锤 + 两个已验证可用的规避方案

感谢 @i-nekoo 的 A 和 B 对照测试，结论与我的最新复现完全一致。补充今天的新发现：

1. 根因实锤：peer dependencies 回溯是死循环的引擎

在 0.1.1-rc.2 上再次复现卡死后，我做了关键对照实验：

命令	结果
npx @deepseek-ai/dsh web	卡死：日志冻结在 placeDep，node 进程 CPU 累计 171s、内存 472MB、netstat 零连接
npx --legacy-peer-deps @deepseek-ai/dsh web	几分钟内正常装完并启动

跳过 peer 解析就不再卡死——死循环的引擎就是 Arborist 对这棵 peer 依赖树的摆放回溯。

2. 但 --legacy-peer-deps 单用会崩：缺 19 个“纯 peer 包”

dsh 生态的子包共声明了 110 个 peerDependencies，其中 19 个只以 peer 形式存在（没有任何包把它们列为常规依赖），跳过 peer 解析后它们不会被安装，启动时直接：

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@deepseek-ai/cordis-plugin-group'
imported from .../dsh-app-boot/lib/index.js

缺失的 19 个包：cordis-plugin-group、dsh-anonymous-user-id、dsh-atomic-write、dsh-authorization、dsh-bash-local、dsh-code-runtime、dsh-compaction、dsh-fs、dsh-invariants、dsh-output-retention、dsh-sandbox、dsh-scope、dsh-session-telemetry、dsh-session-title-llm、dsh-shell、dsh-spill、dsh-subagent-in-process-driver、dsh-timeout、dsh-workflow

这 110 个 peer（多为 ^0.1.1-rc.2 这类宽 range、互相交叉引用）正是 Arborist 组合爆炸的燃料。

3. 为什么症状会“变来变去”（同一个 bug 的三种形态）

阶段	依赖树状态	症状
昨天首次运行	latest=rc.1，部分子包 rc.2 尚未发布	peer 解析失败，反复打印 Could not resolve dependency 警告
今天清缓存后	latest=rc.2，子包齐全	回溯组合爆炸，静默卡死烧 CPU
加 --legacy-peer-deps	跳过 peer 解析	不卡了，但缺 19 个纯 peer 包，运行时崩溃

清缓存、换镜像对此永远无效——问题在解析算法不在网络。

4. 两个已验证可用的规避方案（Windows 11 + Node 24 + npm 11.17 实测，dsh web 成功启动、127.0.0.1:3080 返回 200）

方案 A：pnpm（推荐）

pnpm dlx @deepseek-ai/dsh web

方案 B：纯 npm——把 dsh + 上述 19 个缺失 peer 显式写成直接依赖，再用 --legacy-peer-deps 安装：

npm install @deepseek-ai/dsh @deepseek-ai/cordis-plugin-group @deepseek-ai/dsh-anonymous-user-id @deepseek-ai/dsh-atomic-write @deepseek-ai/dsh-authorization @deepseek-ai/dsh-bash-local @deepseek-ai/dsh-code-runtime @deepseek-ai/dsh-compaction @deepseek-ai/dsh-fs @deepseek-ai/dsh-invariants @deepseek-ai/dsh-output-retention @deepseek-ai/dsh-sandbox @deepseek-ai/dsh-scope @deepseek-ai/dsh-session-telemetry @deepseek-ai/dsh-session-title-llm @deepseek-ai/dsh-shell @deepseek-ai/dsh-spill @deepseek-ai/dsh-subagent-in-process-driver @deepseek-ai/dsh-timeout @deepseek-ai/dsh-workflow --legacy-peer-deps
node_modules/.bin/dsh web

（447 个包约 2 分钟装完，无卡死）

5. 给官方的建议（更新）

1. 短期：README 里注明 npx 在 npm 上可能无限卡死，推荐 pnpm dlx 作为首选安装方式
2. 中期：排查 peerDependencies 的循环和交叉引用结构（@i-nekoo 也怀疑 cyclic peerDependencies），评估将子包间 peer 改为常规 dependencies 的可行性——pnpm 能装说明语义上等价可行
3. 也建议顺手向 npm 和 cli 报一个 Arborist 卡死的 reproducer，这是解析器最坏情况的真实样本