.NET 8 SDK Docker镜像在GitLab CI中执行dotnet restore耗时过长求助
2026-4-21
.NET 8 SDK Docker镜像在GitLab CI中执行dotnet restore耗时过长求助
这种突然从几十秒飙到几十分钟的情况真的太闹心了！结合你提到的CPU占用超100%的细节，我给你几个实际可行的排查和解决方向：
- 先搞定
--no-cache这个参数
你本地恢复快大概率是用到了本地的NuGet缓存，但CI里加了--no-cache等于强制每次都重新下载所有包，再加上.NET 8的NuGet客户端在依赖解析逻辑上有调整，直接放大了耗时。建议先去掉这个参数，同时在GitLab CI配置里加上NuGet缓存：
在.gitlab-ci.yml中添加缓存配置：
cache: paths: - ~/.nuget/packages/
这样后续CI任务就能复用已经下载过的包，不用每次从零开始。
- 排查Runner的资源配置
虽然显示CPU超100%，如果你的Runner是单核配置，那100%就是满负载跑不动了。可以让运维给Runner分配更多CPU核心，或者如果用的是Kubernetes Runner，给CI任务设置更高的资源配额。另外，试试关闭.NET的遥测功能，减少不必要的后台开销，在dotnet restore前加一句：
export DOTNET_CLI_TELEMETRY_OPTOUT=1
- 检查NuGet包源的访问速度
有可能默认的NuGet源在CI环境里访问很慢，试试换成国内的镜像源。比如在项目根目录添加一个NuGet.Config文件：
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="aliyun-nuget" value="https://mirrors.aliyun.com/nuget/v3/index.json" /> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> </packageSources> </configuration>
或者直接在dotnet restore命令里用--source参数指定最快的那个源。
清理项目里的冗余依赖
.NET 8对依赖解析的严格性有所提升，如果项目里有大量过时包、版本冲突的依赖，或者重复引用的包，会让NuGet花大量时间去处理。你可以在本地用dotnet list package --outdated检查过时包，清理掉不必要的依赖，或者统一依赖版本，减少解析压力。试试指定具体版本的SDK镜像
你用的dotnet/sdk:8.0是滚动更新的镜像，可能某个版本存在隐性的性能bug。试试换成具体的小版本，比如dotnet/sdk:8.0.200，说不定能解决问题。
备注：内容来源于stack exchange，提问作者godo57
