换机迁移 DSH Plugin market 插件实录：导出完整清单、按版本重装与逐项验收

我换过三次工作机，只有一次迁移后当天就能正常干活，差别不在网速，而在有没有把版本和配置一起搬。 DSH Plugin market 能帮我确认条目，却不能替我把旧机的 profile 差异带过去。 下面按我自己的顺序，讲哪些东西跟着走、哪些必须重装，以及迁移完怎么验收。

迁移 DSH Plugin market 插件时，什么跟着我走

真正跟着我走的是清单、版本号和 profile 差异，不是插件目录本身。

我会把当前 profile 的已装项、每个插件的确切版本、启用了哪些 profile 以及只在特定 profile 里加载的插件都记下来。 环境变量的名字、凭据的引用方式、插件自己的配置文件也要单独列一份，但只记引用，不把密钥写进迁移文件。 清单越具体，新机上需要临场判断的地方就越少。

不会跟着走的东西同样要心里有数：node_modules、平台相关的原生产物、下载缓存和绝对路径都不该跨机器复制。 旧机是 Intel Mac、新机是 Apple Silicon 时，带原生模块的插件几乎一定要在新机上重新构建。 把这些边界想清楚，迁移就不会变成「拷过去再逐个修」的体力活。

离开旧机前，我用一段命令导出 DSH Plugin market 清单

旧机上最有价值的不是插件目录，而是一份带确切版本的清单和一份 profile 差异记录。

我会先运行下面这段命令，把已装插件、profile 列表和 Harness 版本各存一份文本。 截图只能证明「当时看起来是这样」，文本才能逐行比对，也方便以后回查。 命令本身不复杂，关键是把它存成文件而不是留在终端历史里。

dsh plugin list > dsh-plugins.txt
dsh profile list > dsh-profiles.txt
dsh --version > dsh-version.txt

导出后我会检查清单里每一行是否都有「包名 + 版本」，缺版本的条目当场补上。 如果某个插件是从 Git 仓库或本地路径安装的，我会额外记下来源，因为它不一定能从公共源重装。 这份清单不只是给新机用，出问题时它也是判断「到底少了什么」的底稿。

新机准备：DeepSeek Harness 与包管理器先对齐

本体版本和包管理器不一致，后面的重装会以各种形式失败。

我会先确认新机的 Harness 版本：与旧机同版本最稳，跨大版本则要先读兼容说明。 npm 或 pnpm 的版本也尽量接近旧机，锁文件格式和构建审批策略的差异会在安装原生模块时放大。 版本差异不只影响功能，也会改变依赖解析的结果。

网络同样要提前确认，目标机必须能访问插件所在的包源，内网环境要先准备镜像或离线包。 数据目录的写权限也要检查，装完却无法加载，很多时候不是插件坏了，而是目录不可写。 我会先装一个最小插件跑通全链路，再开始批量迁移，避免一次失败后不知道从哪查起。

如果新机要跨操作系统，原生模块、路径分隔符和权限模型都要额外验证。 我会把这类插件列成单独一组，装完后逐个跑真实操作。 跨平台迁移时，宁可多花时间验证，也不要把旧机的默认路径直接写进配置。

按清单重装 DSH插件：我为什么坚持写死版本

批量重装时我只用「包名@版本」，不让目标机替我决定最新版。

迁移的目标是行为一致，不是顺手升级，默认安装最新版会把一个可控的迁移变成一次不可控的变更。 插件市场适合逐项核对，不适合当批量安装的主通道，真正省事的是命令行按清单执行。 这条规则在只有两三个插件时看起来多余，插件多了就能省掉大量返工。

1. 先在目标机装一个最小插件，确认包源和构建链正常。
2. 按清单先装核心插件，每条命令都带确切版本。
3. 核心插件能加载后，再装辅助插件。
4. 每装完一批就运行 dsh plugin list，与旧机清单逐行对照。
5. 发现版本差异先停下，确认是兼容升级还是装错。
6. 把安装输出保存到迁移记录里，失败时能追到具体包。

我不会直接拷贝插件目录，安装结果里包含平台相关产物和链接结构，跨机器复制很容易留下坏链接。 分批次安装也比一次性全装更好定位问题，哪一批出错，范围就缩小到那一批。 如果某一批装完出现异常，我会先卸掉这一批，而不是继续往下装。

迁移后的 DSH Plugin market 验收：版本、加载与配置

装上是起点，能加载、权限一致、配置生效才算迁移完成。

我会先重启 Harness，确认插件进入 ACTIVE，而不是停在 PENDING 或 FAILED。 ACTIVE 之外的任何状态都值得先看日志，而不是反复重装。 然后抽一个涉及文件或命令的插件跑一次真实操作，确认权限边界与旧机一致。

配置也要逐项看，尤其是路径、密钥引用和只在某个 profile 生效的参数。 再开一个新会话，确认工具和命令都在，而不是只在设置页里显示已安装。 我的完成标准是「清单一致 + 加载正常 + 一次真实操作成功」，缺一项都不算迁移结束。

这次换机教会我的 DSH Plugin market 迁移边界

迁移最容易出错的不是安装命令，而是那些没有写进清单的隐式配置。

我曾经因为一个环境变量没搬，花了半小时怀疑插件版本不对，最后发现只是路径指向了旧机器。 也试过直接拷贝目录，结果原生模块在新架构上加载失败，重装反而更快。 这类问题不会出现在清单里，却会在第一次真实操作时暴露。

旧机器我会保留到验收完成之后，期间不清理配置和缓存，给自己留一条回退路径。 如果目标机版本必须升级，我会把升级和迁移分开做，先保证迁移后与旧机一致，再单独评估升级。 迁移的终点不是「列表看起来一样」，而是新机上能跑通一次旧机最常用的任务；那一刻我才会关掉旧电脑。