卸载 dsh 会把 Node、npm 或 pnpm 一起删掉吗？

不会。卸载 dsh 用的是包管理器的卸载，它只移除指定的那一个包，不会动包管理器本体或运行时。npm uninstall -g @deepseek-ai/dsh 移除的是这个全局包，Node、npm、pnpm 作为运行环境与工具，不在它的删除范围内，卸载后仍可正常使用。

卸载 dsh 会影响其他全局安装的包吗？

不会。包管理器的卸载是定向的，只删除被点名的那一个包及其独占依赖，不会连带删除其他全局包；其他包若与该包没有依赖关系，完全不受影响。卸载前后可以用 npm ls -g --depth=0 对比全局包清单，确认识别的删了、该留的还在。

卸载 dsh 用的 pnpm remove -g 会清掉其他项目共用的包吗？

不会。pnpm 的全局 store 是内容寻址、跨项目共享的：多个项目引用同一份内容，remove 只解除当前项目的引用，不会因为一个项目不再用就删掉 store 里被别人引用的内容。要回收未被引用的内容才需要专门的清理操作，而且它也只清没被引用的部分。

卸载 dsh 会影响其他 profile 或其他客户端装的插件吗？

不会。DeepSeek Harness 的插件按 profile 各自装在对应目录里，桌面端独占 profiles/desktop，命令行按 profile 各有一套；卸载一个环境不会删除另一个环境的插件。核对时要逐个环境分别看，桌面端用已安装列表，命令行侧用配置与依赖目录。

什么操作才可能误伤 dsh 与其他项目共用的共享依赖？

真正可能误伤的是「绕过包管理器的手工删除」：例如直接删全局目录、递归强删 store、或误把共用目录当成某个包的专属目录整片删掉。这些操作绕过了包管理器的引用记账，容易删到别的项目仍在用的内容。正常用包管理器卸载，则不会发生这种误伤。

卸载 dsh 会误删共享依赖吗？DeepSeek Harness 与 Node、pnpm、其他插件的边界

卸载 dsh 不会误删共享依赖：npm uninstall -g @deepseek-ai/dsh 只移除这一个全局包，不动 Node、npm、pnpm 本体，也不动其他全局包；pnpm 的全局 store 是内容寻址、跨项目共享的，pnpm remove -g 不会清掉别人共用的内容（来源）。

这篇按「卸载只动什么 → 共享 store 为什么安全 → 什么操作才会误伤」三步讲。三种装法各自怎么删见《卸载 dsh 的方法汇总》，本文落点是影响范围。

卸载 dsh 只移除一个全局包，不动运行时与包管理器

npm uninstall -g @deepseek-ai/dsh 移除的是这个指定的全局包及其独占依赖；Node、npm、pnpm 作为运行环境与工具不在删除范围内，其他无关全局包也不受影响（来源）。

按下面四步先记录、再卸载、后核对：

记录卸载前的全局包清单 — 跑 npm ls -g --depth=0（pnpm 用 pnpm ls -g）。预期：得到一份基线清单，作为对比依据。
确认运行时版本仍在 — 跑 node -v、npm -v、pnpm -v。预期：卸载前后版本不变，说明运行时没被牵连。
执行定向卸载 — 跑 npm uninstall -g @deepseek-ai/dsh（或对应包管理器的卸载）。预期：只报告移除该包，条目消失。
对比全局包清单 — 再跑一次 npm ls -g --depth=0。预期：只有目标包消失，其他全局包仍在。

第 4 步是最直接的验证：定向卸载的差别应该「只有一行」。如果对比发现别的包也少了，多半不是卸载命令所为，而是这些包本身就依赖被卸的那个包——这时才需要评估是否补装。

共享 pnpm store 为什么安全：内容寻址、跨项目共享

pnpm 的全局 store 是内容寻址、跨项目共享的：相同内容只存一份，多个项目引用同一份；pnpm remove -g 只解除当前项目的引用，不会删除仍被其他项目引用的内容（来源）。

用命令理解并确认安全：

定位 store — 跑 pnpm store path。预期：得到共享的 store 目录。
看谁在引用 — 分别在各个项目 / profile 里跑 pnpm ls 看依赖。预期：多个环境可能都指向 store 里同一份内容。
移除当前引用 — 跑 pnpm remove -g <包名> 或按项目卸载。预期：当前环境不再引用，store 内容因仍被他人引用而保留。
需要时才清未引用内容 — 跑 pnpm store prune。预期：只清掉没有任何引用的内容，被引用的不动。

第 3、4 步的区别就是「安全」的来源：remove 处理的是引用，prune 处理的是没被引用的残留。两者都不会因为一个项目不再使用就删掉其他项目正在用的包，这正是内容寻址存储带来的共享便利。

什么操作才会误伤共享依赖

真正可能误伤的是绕过包管理器的手工删除：直接删全局目录、递归强删整个 store、或把共用目录当专属目录整片删除；正常的包管理器卸载有引用记账，不会发生这种误伤（来源）。

对照下面几类操作，避开会误伤的做法：

手工删全局目录 — 直接删 npm root -g 下的目录会连同其他全局包一起删。预期：危险；改用包管理器定向卸载。
递归强删 store — 直接清空 pnpm store path 会让所有引用它的项目缺内容。预期：危险；需要回收时用 pnpm store prune。
把共享目录当专属目录删 — 误判某个目录只属于 dsh，整片删除。预期：危险；先确认引用再决定。
正确的核对习惯 — 删除前后用 npm ls -g --depth=0 与 pnpm ls 对比。预期：只少该少的，才算安全卸载。

第 2 类最容易被忽视：store 是共享的，看上去「就是个缓存目录」就直接清空，别的项目会立刻缺依赖。记住 remove 与 prune 的分工，就不需要冒这个险。

卸载 dsh 与共享依赖的注意事项

用包管理器卸载：定向卸载只删指定包，比手工删目录安全得多。
运行时不在范围内：Node、npm、pnpm 是工具，不随包卸载消失。
store 共享：需要回收用 pnpm store prune 清未被引用的内容，别整片删。
按 profile 各管各的：卸载一个环境的插件不影响其他环境。
前后对比清单：用全局包清单与依赖列表确认「只少该少的」。

其他 profile 或客户端装的 DSH插件要逐处核对，桌面端打开 DSH Plugin Hub 已安装列表最直观；命令行侧回到各自 profile 查，分开看就不容易把共享与专有搞混。

来源：npm Docs: npm uninstall、pnpm Docs: pnpm remove、DeepSeek Harness 命令行 README（官方仓库）