根本原因是VSCode默认调用全局.NET SDK的dotnet命令，严格读取NuGet.Config中不可达、过期或被墙的源导致服务索引加载失败；实操需检查源列表、精简配置、验证私有源可达性，并禁用OmniSharp自动还原。
为什么 dotnet restore 在 VSCode 里总报“Unable to load the service index for source”
根本原因是 VSCode 默认调用的是全局 .NET SDK 的 dotnet 命令，而该命令在执行 dotnet restore 时会严格读取 NuGet.Config 配置（包括源地址、凭据、代理），一旦配置中存在不可达的私有源、过期的认证或被墙的官方源（如 https://api.nuget.org/v3/index.json 无法访问），就会卡在服务索引加载阶段，且错误信息不提示具体哪个源失败。
实操建议：
- 先在终端运行
dotnet nuget list source，确认当前生效的源列表； - 检查项目根目录或用户目录（
%APPDATA%\NuGet\NuGet.Config或~/.nuget/NuGet/NuGet.Config）下的NuGet.Config文件，注释掉所有非必需的<add key="..." value="..."></add>行，只保留可信的本地或离线源； - 若公司内网有私有源，确保其 URL 可被
curl -I https://your-nuget-server/v3/index.json访问（注意是v3/index.json，不是v3/）； - VSCode 中禁用自动还原：在设置里搜索
omnisharp.autoRestore，设为false，改用手动触发dotnet restore --force控制流程。
如何让 VSCode + OmniSharp 离线使用已下载的 NuGet 包
离线工作的前提是：包文件（.nupkg）已存在于本地缓存，并且项目能跳过远程源验证。NuGet 默认缓存路径是 ~/.nuget/packages（Linux/macOS）或 %userprofile%\.nuget\packages（Windows），但仅靠缓存目录还不够——dotnet restore 仍会尝试连接源来校验元数据。
实操建议：
- 用
dotnet restore --no-cache --ignore-failed-sources强制跳过网络校验（注意：.NET 6+ 支持--ignore-failed-sources，旧版本需升级 SDK）； - 在
NuGet.Config中添加离线源：<configuration> <sources> <add key="offline" value="C:\path\to\offline-packages" /> </sources> </configuration>然后把已解压的.nupkg内容（即按id/version/目录结构组织）拷入该路径； - OmniSharp 不读取
NuGet.Config的<disabledPackageSources>，所以必须显式禁用远程源，例如：dotnet restore -s "C:\offline" -s "https://api.nuget.org/v3/index.json" --disable-parallel，把离线源放在前面，再加--disable-parallel避免并发请求触发失败源； - 确认
csproj中没有<RestoreSources>或<PackageSourceUrl>覆盖行为。
VSCode 里 OmniSharp 显示 “The project file cannot be loaded” 且日志含 “Could not resolve SDK ‘Microsoft.NET.Sdk’”
这不是 NuGet 问题，而是 OmniSharp 找不到 .NET SDK 安装路径，导致连项目解析都失败，后续的 restore 更无从谈起。常见于多版本 SDK 共存、PATH 混乱或 VSCode 终端与 GUI 启动环境不一致。
实操建议：
- 在 VSCode 内置终端运行
which dotnet（macOS/Linux）或where dotnet（Windows），对比系统终端输出，若不一致，说明 VSCode 没继承正确 shell 环境； - 在 VSCode 设置中配置
omnisharp.dotnetPath，设为完整 SDK 路径，例如/usr/share/dotnet或C:\Program Files\dotnet； - 不要依赖
global.json的sdk.version锁定旧版 SDK，除非明确需要——OmniSharp 对 SDK 版本敏感，.NET 8 SDK 可能无法加载标为net6.0且含旧 MSBuild 任务的项目； - 删除
.omnisharp\缓存目录后重启 VSCode，避免旧状态干扰。
离线场景下 dotnet build 成功但 VSCode 仍标红“找不到类型”
这是 OmniSharp 的语义分析未同步 restore 结果的典型表现。即使 dotnet build 能成功（因为它走的是 CLI 自己的依赖解析路径），OmniSharp 仍会独立执行自己的 restore 流程，且默认不复用 CLI 的 obj/project.assets.json 缓存。
实操建议：
- 确保
omnisharp.useGlobalMono设为never（默认值），避免它误用 Mono 的旧解析器； - 在
csproj中显式指定<RestorePackagesPath>，例如：<PropertyGroup> <RestorePackagesPath>$(MSBuildThisFileDirectory)packages</PropertyGroup>
再配合-p:RestorePackagesPath=...手动传参，让 OmniSharp 和 CLI 共享同一 packages 目录； - 检查 OmniSharp 日志（命令面板 > “OmniSharp: Show Log”），搜索
Project loaded和Dependencies resolved，确认是否真加载了全部包； - 如果用了
Directory.Build.props注入PackageReference，OmniSharp 可能不识别——这类全局注入需确保 props 文件位于解决方案根目录，且被dotnet sln add正确关联。
httpCache 目录（~/.local/share/NuGet/HttpCache 或 %localappdata%\NuGet\v3-cache）不会被 --no-cache 清除，但它存储的是源响应快照，有时反而会干扰离线判断。真要彻底离线，删掉这个目录比调参数更直接。 
