dsh plugin update 为什么没有把插件升到最新的大版本？

因为 dsh plugin 把参数原样转发给 pnpm，而 pnpm update 只做版本范围内的小步更新，不会跨过大版本边界。dsh plugin update 会遵守 profile 的 package.json 里记录的版本范围（如 ^ 限在同一大版本内），所以想跨大版本要用 add 指定目标版本。

dsh plugin 怎么安装或更新到预发布版本？

用 pnpm 的 dist-tag 指定预发布通道，例如 dsh plugin --profile web add dsh-memory@next，或直接写完整预发布号 dsh plugin --profile web add dsh-memory@1.3.0-rc.0。dsh plugin 把参数转发给 pnpm，tag 与预发布号都按 pnpm 规则解析。

dsh plugin 怎么把插件版本固定在某个精确版本？

用 add 装精确版本：dsh plugin --profile web add dsh-memory@1.2.3。该命令会同时更新 profile 的 package.json 与依赖，pin 住之后普通的 update 不会轻易把它挪走。基础的单插件更新步骤见《dsh 更新插件用什么命令》。

dsh plugin update 之后怎么确认实际生效的版本号？

跑 dsh plugin --profile web outdated 对比 Current 与 Latest 能看到更新前后的差异；也可以用 dsh plugin --profile web list 直接查已安装版本。profile 的 package.json 记录的是版本范围，真正解析出的精确版本记录在锁文件里。

dsh plugin 的版本范围写在哪个文件里，能直接改吗？

版本范围写在当前 profile 的 package.json 里，路径是 $DSH_HOME/profiles/ 。你可以在那次 profile 里改，但更稳的做法是用 add 指定版本，让包管理器同时更新 package.json 与锁文件，避免范围被手改成无效约束。

dsh plugin 怎么更新到指定版本？DeepSeek Harness 插件预发布、版本范围与锁定用法

dsh plugin 更新到哪个版本，取决于 profile 里记录的版本范围：dsh plugin --profile <name> update <pkg> 把参数原样转发给 pnpm，而 pnpm 的 update 只做版本范围内的小步更新，跨不了大版本；要升预发布用 dist-tag，要钉精确版本用 add 包名@版本（来源）。

基础的单插件更新步骤、失败兜底和回滚，见《dsh 更新插件用什么命令》。这篇只解决一个更细的问题：为什么你执行了 update，DeepSeek插件却没到你想要的那个版本——答案藏在版本范围、dist-tag 与锁文件里。

为什么 dsh plugin update 升不到你要的版本：版本范围语义

update 走的是「范围内小步更新」，它尊重 profile 的 package.json 里声明的版本范围，不会为了追最新而跨过大版本边界（来源）。

先看一张范围对照表：

范围写法	含义	update 能做到的
`1.2.3`	精确锁定	原地不动
`~1.2.3`	同小版本	最多升到 `1.2.x`
`^1.2.3`	同大版本	最多升到 `1.x`
`*`	任意版本	可跨大版本

看懂版本范围要抓住五点：

范围写在 profile 的 package.json 里 — 路径是 $DSH_HOME/profiles/<name>，插件作为树外依赖记录在此。预期：你能在这里看到每个插件声明的范围。
^ 与 ~ 放宽程度不同 — ^1.2.0 允许升到同大版本内的最新，~1.2.0 只允许升到同小版本内。预期：update 的结果由范围决定，不由「有没有更新版本」决定。
跨大版本要显式指定 — 当插件出了 2.0.0 而范围是 ^1.2.0，update 不会把它升上去。预期：outdated 里会显示 Latest 已经更高、但 update 后 Current 仍在 1.x，这就是范围在起作用。
范围是上限，不是目标 — update 只取范围内可得的最高版本，不会主动跳出范围。预期：即便 registry 上有更高版本，Current 依然停在范围边界内。
核对范围用只读命令 — 执行 cat "$DSH_HOME/profiles/web/package.json"（Windows 用 type）。预期：一眼看到每个插件名右侧对应的范围字符串，不用猜。

dsh plugin 怎么更新到指定版本或用 tag 升到预发布

升到指定版本或预发布，靠的是 pnpm 的 add：dsh plugin --profile <name> add <pkg>@<version> 装精确版本，@next 这类 dist-tag 则解析到对应的预发布通道（来源）。

先按目标选写法：

目标	写法
升到指定正式版	`add dsh-memory@1.2.3`
升到预发布通道	`add dsh-memory@next`
回退到旧版本	`add dsh-memory@1.1.0`

按目标分五种写法：

升到指定正式版本 — 执行 dsh plugin --profile web add dsh-memory@1.2.3。预期：package.json 与依赖被同步更新，装到该精确版本。
升到预发布通道 — 执行 dsh plugin --profile web add dsh-memory@next，或直接写完整预发布号 dsh-memory@1.3.0-rc.0。预期：解析到该 tag 指向的预发布版本；预发布通常不在默认 latest 通道上，必须显式指定。
收窄范围来固定行为 — 把范围写成精确版本，让后续 update 不再自动挪动它。预期：以后普通 update 会跳过这个插件，直到你再次用 add 改范围。
回退到旧版本同样是 add — 写 dsh plugin --profile web add dsh-memory@1.1.0。预期：范围与锁文件一起被拉回旧版本，比手动改 package.json 再装更干净。
一次只动一个插件 — 命令行里明确写包名，不批量猜。预期：其他插件的范围不会被顺手刷新，出问题时范围更小。

profile 的 package.json 与锁文件：怎么确认实际生效版本

范围记在 package.json，实际解析出的精确版本记在锁文件；确认生效版本看这两个文件，或直接用 outdated 与 list（来源）。

五步核对：

先跑 outdated 看差异 — dsh plugin --profile web outdated 会列出 Current、Latest、Want 三列。预期：Want 是范围内能到的版本，Latest 是 registry 上的最新版本，两者不一致通常就是范围卡住了。
再查已装版本 — dsh plugin --profile web list 直接看当前安装版本。预期：确认更新真的落到了目标版本，而不是只改了 package.json。
直接读 profile 的 package.json — 执行 cat "$DSH_HOME/profiles/web/package.json"（Windows 用 type）。预期：看到每个插件声明的范围，确认它是不是卡住 update 的那一条。
直接读锁文件 — 执行 cat "$DSH_HOME/profiles/web/pnpm-lock.yaml"。预期：看到实际解析出的精确版本与依赖关系，范围很宽时以它为准。
对比范围与解析结果 — 把第 3 步的范围和第 4 步的精确版本摆在一起。预期：两者一致说明状态干净；若 package.json 的范围与锁文件解析对不上，说明有人手改过。

dsh plugin 更新到指定版本的注意事项

update 不跨大版本是设计，不是 bug — 想跨就显式用 add 指定，别反复重试 update。
预发布要自己担兼容风险 — dist-tag 指向的版本可能未与当前 DeepSeek Harness 完全对齐，装完先恢复到可用版本更稳。
别手改范围了事 — 直接编辑 package.json 可能导致范围与锁文件不一致，用 add 让两者一起更新。
profile 不同范围也不同 — 每个 profile 有独立的 package.json 与依赖，按 profile 更新插件见《dsh plugin 按 profile 更新怎么操作》。
先用范围判断该用哪条命令 — 目标版本落在范围内就走 update，落在范围外就走 add。预期：少一次注定不生效的重试。
别把预发布和正式版混着记账 — 混装之后 outdated 的 Latest 指向的通道不一样，判断容易被误导。预期：把预发布单独记一笔，更新时心里有数。

不想记这些范围与 tag 的差别，用 DSH Plugin Hub 更直接：它在已安装列表里标出可更新的 DSH plugin，点一下就能处理，更新前的确认弹窗会告诉你即将升到哪个版本。

来源：dsh CLI 参数定义（源码）、dsh CLI README、pnpm update 官方文档、pnpm add 官方文档