NuGet 删除旧包后，客户为何还能恢复它

摘要

周五，产品经理关掉旧产品的宣传页，宣布团队终于可以集中火力做下一代。周一，客户重建项目，旧依赖又从 NuGet 回来了。

这是一幅假设场景，却准确展示了退休计划里容易漏掉的权力边界：卖方能撤走招牌，未必能把买方生产线上的零件一起收走。软件没有占用仓库，旧版本却占用日程、测试资源，以及那个还记得它为什么这样设计的人的脑子。

NuGet.org 的规则把这件事说得很直接。普通删除实际上是取消列出：软件包从通常的搜索和版本展示中退场，但指定版本仍可下载、安装、恢复。浮动版本恢复也存在例外：若被取消列出的版本仍是满足约束的最新版本，它可能继续被选中。目录复制机制同样包含这些包。NuGet 删除政策

所以，搜索框里的清静，只能证明搜索框清静。它无法替客户证明依赖已经换掉。

连同一个命令，到了不同地方也有不同权限。官方 nuget delete 文档区分得很清楚：目标是 NuGet.org 时执行取消列出；目标是本地文件夹时，才是删除文件。NuGet 删除命令说明

这让一个看似简单的管理动作变成了采购问题。供应商说“我们已经删除旧包”，买方应知道它究竟从哪里消失。删除了开发者的本地副本，撤下公共目录的展示，还是客户已改过自己的依赖配置，后果各不相同。

公共仓库保留旧版本，有清楚的商业理由。今天重建昨天的项目，如果只能拿到今天的新零件，所谓重复构建就成了抽奖。发布者随时擦掉历史，代价会落到当初依赖它的人身上。平台选择保护这条连续性，也就限制了发布者通过普通目录操作催促客户搬家的能力。

NuGet 团队对有害或侵权等特殊内容保留移除路径。这是处理特殊内容的权限。一个产品经理想少养一条产品线，走的是另一套商业决策。

发布者还有弃用功能，可以说明原因，并推荐替代软件包及版本。弃用和取消列出各自独立，可以同时采用，也可以只做其中一项。官方文件另有一个容易被长篇公告掩盖的细节：自定义弃用消息展示在 NuGet.org 网站，客户端不会照单展示这段自定义文字。NuGet 弃用及热度转移规则

支持的 Visual Studio 版本能在已安装软件包页面显示弃用信息；相应的 dotnet 命令可主动查询弃用依赖。这里的动词是显示和查询。团队若从不进入那个页面，也没有把查询放进自己的工作，发布者写得再动情，客户也可能继续按照原来的配置完成构建。

通知设计因此属于迁移成本。网页上给出一份漂亮的替代方案，尚未回答谁会看到它、谁负责修改、谁承担回归测试。供应商省下的说明成本，可能变成客户工程师的搜索成本；客户迟迟不动，又会变成供应商客服的重复解释成本。

最便宜的公告，常常要由最贵的人读懂。

NuGet 还允许申请把旧包的内部热度分数转给替代包，帮助后者获得相应搜索位置。实际下载计数保持原样。把搜索积累交给后继者，是平台提供的一种接续工具；历史数字没有因此改姓，客户项目里的包名也没有自动改写。

这项转移需要审查。相关包必须共享全部所有者，名称或功能有明确关联，旧包各版本要标记弃用并指向替代者，新包要有稳定版本，而且不能制造搜索混淆。一个旧包最多可把热度转给五个新包，分数均分。已接受其他包热度的包，不能再作为转出端接着传。

均分尤其值得产品负责人留意。把旧套件拆成几个模块，技术边界可以按功能决定；搜索声誉的分配却按平台给定的规则进行。最重要的新模块不会因为业务负责人最喜欢它，就自动分到更多历史热度。

这是一种受规则约束的分发资本。积累来自过去，兑现方式由目录决定。收购团队若把“拿到旧包名”“继承搜索位置”“留住客户”写成同一项资产，会把三个需要分别完成的任务压成一个好看的数字。

NuGet.org 以软件包所有者权限管理发布和交接。包内作者元数据不决定谁拥有这些权限。交接通常先添加新所有者，由对方接受邀请，再按需要移除旧所有者；等待接受的邀请仍只是待办事项。NuGet 发布与所有者管理

对想关闭旧产品线的公司，这个细节比庆功邮件实在。新团队接到了文档，却没有接到权限，后续更新仍要寻找旧负责人。权限交完了，却没人保留兼容性知识，下一次客户迁移又会把退休的人请回来。

这些规则没有给出某个供应商还剩多少客户、多少支持义务。要算它的退休账，需要实际依赖版本、支持约定和已经完成的迁移记录。拿到这些资料后，成本才有落点：哪些客户还能自行转移，哪些需要协助，哪段知识一旦解散就很难买回来。

旧包继续可取，对客户可能是救生绳；对想收摊的供应商，则是一份迟迟没有签收的交接单。把两边的账分开，才能讨论谁该出钱让这次搬家真正发生。