确认当前生效的NuGet包源需在Package Manager Console执行Get-PackageSource或dotnet nuget list source，并检查%appdata%\NuGet\NuGet.Config及解决方案级NuGet.Config中是否被clear或disabledPackageSources屏蔽。
Visual Studio 里配置 C# 项目的 NuGet 依赖，核心就两件事：包源得对、安装方式得匹配项目格式。错一个，Install-Package 就报找不到包，或装上后 using 不进命名空间。
怎么确认当前生效的 NuGet 包源？
很多人改了源却没生效，是因为 Visual Studio 实际读取的是多个配置文件的叠加结果，不是 UI 里看到的那一条。
- 打开
工具 → NuGet 包管理器 → 包源管理器，列表里勾选的源才参与搜索和安装 - 但真正起作用的还有隐藏配置：Windows 下优先读
%appdata%\NuGet\NuGet.Config，其次才是解决方案根目录下的NuGet.Config - 如果本地有私有源（比如公司 Nexus 或 Azure Artifacts），URL 必须是 v3 协议地址，形如
https://your-company.pkgs.visualstudio.com/_packaging/FeedName/nuget/v3/index.json；v2 地址（带/nuget/v2）在新版本 VS 中默认被禁用 - 私有源需要认证时，不能只填 URL —— 必须提前在 Windows 凭据管理器里存好对应域名的用户名密码，否则
Find-Package能搜到，Install-Package却卡在 401
SDK 风格项目 vs packages.config 项目，安装行为完全不同
项目文件里有没有 <Sdk="Microsoft.NET.Sdk"> 这行，决定了 NuGet 怎么记依赖、怎么还原、甚至能不能装成功。
- SDK 风格项目（.NET Core / .NET 5+ / .NET Standard 类库等）：依赖直接写进
.csproj，用PackageReference元素。此时Install-Package命令会自动更新项目文件，不需要packages.config - 传统 .NET Framework 项目（非 SDK 风格）：默认用
packages.config记录依赖。如果强行在它上面执行Install-Package，VS 可能弹窗问“是否迁移到PackageReference？”——选否就继续走旧流程，选是则重写依赖结构，已有自定义MSBuild逻辑可能失效 - 混用风险：一个解决方案里既有 SDK 风格又有非 SDK 风格项目时，全局
NuGet.Config的<disabledPackageSources>设置可能只对其中一类生效，导致某几个项目搜不到包
Package Manager Console 里哪些命令真有用？
UI 点点点适合初装，但修复、批量操作、CI 流程必须靠控制台。别迷信 Update-Package，它不解决引用丢失问题。
-
Find-Package -Source "nuget.org" -AllVersions Newtonsoft.Json：强制指定源查所有版本，避免被本地缓存或禁用源干扰 -
Install-Package Newtonsoft.Json -Version 13.0.3：显式指定版本最稳，尤其当你发现默认装的是预发行版（带-alpha后缀）时 -
Update-Package -reinstall：只对已安装包有效，且仅重装当前项目所列版本；它不会升级到新版本，也不会拉取缺失的间接依赖（比如 A 依赖 B，B 依赖 C，C 缺失时这个命令不补） - 真正补全依赖链要用：
dotnet restore（SDK 项目）或Update-Package -ProjectName YourProj -Reinstall（非 SDK 项目）
为什么装完包却 using 不进命名空间？
这不是包没装上，而是引用路径或目标框架不匹配。常见于跨平台或升级项目。
- 检查项目目标框架是否被包支持：比如装
Microsoft.Data.SqlClient到.NET Framework 4.6.1项目，它最低要求 4.6.2，就会静默失败 - SDK 项目中，如果
.csproj里手动加了<PackageReference Include="xxx" Version="x.x.x" PrivateAssets="all" />，那该包的程序集不会被输出到bin目录，自然也using不进来 - 装完后没触发自动还原？右键项目 →
还原 NuGet 包，或者删掉obj/project.assets.json再重建——这个文件才是真实依赖图，比 UI 显示更准 - 多目标项目（
<TargetFrameworks>net6.0;netstandard2.0</TargetFrameworks>）下，某些包只兼容其中一个框架，VS 可能默认选错目标再编译，导致命名空间不可见
最易被忽略的一点：NuGet 配置是分层叠加的，用户级、解决方案级、计算机级配置会互相覆盖。调试时别只盯着 UI 里的包源列表，先用 dotnet nuget list source 或 Get-PackageSource 在控制台里看实际生效的源，再查对应 NuGet.Config 文件里有没有 <clear /> 或 <disabledPackageSources> 暗中屏蔽了你想要的源。
