如何优雅解决NuGet包更新延迟导致的紧急Bug修复发布问题？

针对NuGet包发布后延迟生效的问题，工业界团队通常采用以下几种实用方案：

• 临时使用本地/私有NuGet源
  修复Library后，先将构建好的包发布到公司内部私有NuGet源，或者直接在本地生成nupkg文件。然后修改Product的项目配置，将NuGet源指向私有源或本地包路径——比如在NuGet.Config中添加私有源地址，或者用<PackageReference Include="Library" Version="x.x.x-hotfix" Source="../local-packages/" />直接引用本地包。这样Product可以立即使用修复后的Library，无需等待公共NuGet同步。等公共NuGet的包生效后，再将Product的引用切回公共源的正式版本。

• 临时切换为项目引用
  把Library的源码直接添加到Product的解决方案中，将原有的NuGet包引用替换为项目引用（<ProjectReference Include="..\Library\Library.csproj" />）。修改Library后，编译Product就能直接包含修复后的代码，完全跳过NuGet发布流程。等公共NuGet的Library版本更新完成后，再移除源码项目，换回NuGet引用。这个方案适合极端紧急场景，能最快完成验证和发布，但要注意后续及时清理，避免源码耦合。

• 预发布版本+内部镜像加速
  发布Library时，先推送带预发布后缀的版本（比如1.2.3-hotfix001）到公共NuGet，同时配置公司内部的NuGet镜像源实时同步公共包。内部团队使用镜像源拉取包，能大幅缩短等待时间。Product先引用这个预发布版本完成测试和发布，等正式版本在公共源生效后，再替换为正式版本号。另外，所谓的“数小时生效”很多时候是本地缓存导致的，可执行dotnet nuget locals all --clear强制清理本地缓存，重新拉取最新包。

• 自动化发布与缓存刷新
  如果使用私有NuGet源（如Azure Artifacts、GitHub Packages），可以在CI/CD流程中添加发布后立即刷新缓存的步骤，确保内部团队能马上获取到更新后的包。对于公共NuGet，可通过脚本监控包的可用状态，一旦检测到包已在公共源上线，就自动触发Product的更新和构建流程，减少人工等待时间。

内容的提问来源于stack exchange，提问作者Alex from Jitbit