咨询：使用dotnet/sdk:8.0容器时dotnet restore耗时过长的问题

• 启用GitLab CI NuGet缓存：每次流水线默认会重新下载所有NuGet包，这是耗时的核心原因之一。在.gitlab-ci.yml中添加缓存配置，复用已下载的包：

  cache:
    paths:
      - ~/.nuget/packages/
      - **/obj/
    key: $CI_PROJECT_ID-nuget
  

  用项目ID作为缓存键，避免不同项目的缓存冲突。

• 切换国内NuGet源：默认nuget.org源在海外，网络延迟高。可以在项目根目录创建NuGet.config配置国内镜像：

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <packageSources>
      <clear />
      <add key="AzureCN" value="https://nuget.cdn.azure.cn/v3/index.json" />
      <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </packageSources>
  </configuration>
  

  或者在restore命令中直接指定源：dotnet restore --source https://nuget.cdn.azure.cn/v3/index.json

• 优化restore命令：避免扫描整个解决方案，直接指定需要还原的项目文件，减少不必要的操作：

  dotnet restore ./src/YourProject/YourProject.csproj
  

  不要添加--no-cache参数，该参数会强制跳过本地缓存，加重下载负担。

• 检查Runner网络与镜像版本：

  • 若使用自托管GitLab Runner，确认服务器网络带宽充足，防火墙未限制NuGet源的访问；
  • 尝试升级到dotnet/sdk的最新小版本（如dotnet/sdk:8.0.300），早期8.0版本存在部分restore性能缺陷，后续版本已修复。

内容的提问来源于stack exchange，提问作者javidasd