这几年在VS2022里做.NET项目的团队，多少都会碰到同一个问题：项目一多，NuGet包的文件反复下载、重复占用磁盘，内网环境下一还原就报错，不同开发人员本地的包版本还不一致。我这次尝试NuGet共享，起因也很简单——组里有多个解决方案共用同一批第三方依赖，每次新成员拉代码回来还原包都要等半天，部分机器还在隔离内网，根本连不上nuget.org。于是我把VS2022的NuGet共享方案从头到尾捋了一遍，从全局缓存路径调整到本地文件夹源搭建，再到离线环境下的包迁移，折腾下来算是摸清了底细。这篇文章就是这次尝试的完整记录，适合需要给团队统一下依赖、做内网离线开发，或者单纯想省点磁盘空间的朋友参考。
1. 为什么要把NuGet包“共享”起来？
1.1 先看一个典型痛点场景
假设你手上有三个解决方案：一个是Web API，一个是后台任务，还有一个是工具类控制台程序，它们都引用了Newtonsoft.Json、Serilog、OpenCvSharp这些包。默认情况下，VS2022的NuGet还原机制会把每个包解压一份到全局缓存目录，同时每个项目的输出目录里还会复制一份dll。如果三个解决方案各自维护一份引用，磁盘空间就是这么悄悄没的。
更麻烦的是离线环境。很多公司项目不能直接访问nuget.org，新电脑配好环境之后，一执行dotnet restore或VS里的“还原NuGet包”，要么卡在超时，要么报NU1101找不到包。这个时候，如果之前没人做过包共享，就只能拿着U盘从有网的机器一个个拷，非常痛苦。我这次做NuGet共享，本质就是想解决这三件事：让同一台机器上的项目不重复下载同一份包、让离线/内网环境的还原能顺利进行、让团队内部依赖版本保持一致。
1.2 NuGet共享到底共享的是什么
很多刚接触这块的人会有一个误区，以为“共享NuGet包”是把dll放到一个公共目录，然后项目直接引用这个目录。实际上现代SDK风格项目根本不需要这样操作，NuGet的核心机制是“包还原（restore）”。还原时会按照包ID和版本号去特定的缓存目录里找，找到就直接用，找不到才去配置的源里下载。
所以真正值得共享的内容有三个层面。第一个是全局包缓存，也就是同一台机器上多个项目、多个解决方案共用一份已解压的包文件，避免重复下载和重复占空间。第二个是包源，把一个文件夹或者一台服务器作为NuGet源，让团队所有成员的还原请求都从这个源里拿包，而不是每个人都直连公网。第三个是版本策略，通过配置文件把各项目引用的包版本统一锁定，避免“我这能跑你那不行”的经典问题。
1.3 三种共享方式的取舍
我把常见的共享方式分成三种，按投入成本从低到高排了一下：
| 共享方式 | 配置成本 | 适用场景 | 局限 |
|---|---|---|---|
| 统一全局包缓存位置 | 低 | 单机多用户、多个解决方案共用 | 跨机器迁移仍要手动处理 |
| 本地文件夹源 | 中低 | 内网开发、离线还原、小团队 | 包数量多之后不好管理 |
| 私有NuGet服务器（BaGet、Nexus、Azure Artifacts） | 高 | 大团队、CI/CD、精细化权限控制 | 需要服务器和持续维护 |
这次我实际采用的组合是“统一全局缓存目录 + 本地文件夹源”，中间穿插了离线包迁移和版本锁定。这套方案不用搭服务器、不花钱，但已经能把90%的依赖共享问题解决掉。等团队规模大到需要权限控制和包审计时，再考虑私有服务器也不迟。
2. NuGet缓存体系拆解：共享前先摸清家底
2.1 全局包文件夹（global packages folder）
全局包文件夹是NuGet最核心的缓存，位置默认在用户目录下。Windows系统里通常是C:\Users\<用户名>\.nuget\packages，结构大概是这样的：
C:\Users\<用户名>\.nuget\packages\ newtownsoft.json\ 13.0.3\ lib\ newtonsoft.json.nuspec newtonsoft.json.13.0.3.nupkg .nupkg.metadata每个包ID对应一个文件夹，里面按照版本号再分一层，真正的包内容已经解压好了。构建项目时，编译器直接引用这里的dll，所以“还原之后删掉项目bin目录里的输出文件”并不会真正丢东西，只要全局缓存还在，重新构建会自动恢复。这也解释了为什么第一次还原慢、之后还原很快——因为大部分包已经命中本地缓存。
想查看当前全局缓存路径，可以打开命令行执行：
dotnet nuget locals global-packages --list会输出类似global-packages: C:\Users\xxx\.nuget\packages的结果。如果你设置了环境变量NUGET_PACKAGES，这个输出就会变成你指定的路径。
2.2 HTTP缓存与临时目录
除了全局包文件夹，另外两个容易混淆的缓存是HTTP缓存和临时安装目录。HTTP缓存默认在%LOCALAPPDATA%\NuGet\v3-cache，它保存的是NuGet客户端从服务器请求元数据时得到的HTTP响应，用来减少重复请求，但里面不保存完整的包文件内容。清掉HTTP缓存并不会让你丢失已还原的包，最多就是下次还原时重新拉一遍元数据，速度会略慢一点。
临时安装目录一般在系统临时目录下，比如%TEMP%\NuGetScratch，只在安装、更新包的短暂过程中使用。遇到还原中断、磁盘写满这类异常情况，偶尔会有临时文件残留，影响不大但可以随手清理。
做共享时最容易踩的坑，就是只看到全局包文件夹而忽略另外两类缓存。导出包给别人时，正确的原料来源是全局包文件夹里的.nupkg文件，而不是HTTP缓存。拿HTTP缓存目录里的文件去当离线包源，十有八九是缺文件的。
2.3 旧式 packages.config 与本地包目录
如果你的项目还是老式的.NET Framework项目，拖动引用时用的是packages.config而不是PackageReference，包的还原逻辑会有点不一样。这种项目默认会在解决方案根目录生成一个packages文件夹，里面按包ID.版本号存放包内容，项目文件通过相对路径引用dll。
对这类项目做共享，思路和SDK风格项目不同。你不能再指望全局缓存，因为旧项目的还原行为是“把包解压到解决方案的packages目录”。想让团队复用，要么把整个packages目录放到共享盘，要么保留一份完整的离线包压缩包，交给新成员解压到对应位置。VS2022里也可以把老项目迁移到PackageReference模式，迁移之后就能享受全局缓存带来的便利了。不过迁移有风险，页面级依赖、程序集版本绑定的兼容性都要测，我不建议在共享这件事上顺手做大规模迁移。
2.4 NuGet.Config 的配置层级
NuGet的所有配置都集中在一个叫NuGet.Config的XML文件里，但它有多层，而且不同层级的配置会合并。按从低到高排列，大致是机器级、用户级、解决方案/项目级，越靠近项目的配置优先级越高。机器级文件一般在C:\ProgramData\NuGet\Config，用户级是%APPDATA%\NuGet\NuGet.Config，解决方案级就是放在解决方案根目录下的nuget.config。
这个顺序很重要。很多人在用户级里配了本地源，结果发现VS还原时根本没走本地源，就是因为解决方案根目录存在另一个nuget.config，把源列表给覆盖掉了。反过来，如果我们想给团队统一配置，直接在解决方案根目录放一份nuget.config是最有效的做法，它会覆盖成员机器上的用户级设置，保证同一个解决方案在任何机器上还原表现一致。
3. VS2022实操：一步步把NuGet共享配起来
3.1 第一步：确认当前包源与缓存位置
动手之前，先看清现状。打开VS2022，菜单路径是“工具” -> “NuGet包管理器” -> “程序包管理器设置”，左侧点“包源”，能看到当前配置的所有源，默认一般有nuget.org。如果你之前装过一些插件或者公司内部源，这里可能多出几项。
命令行也有对应的查看方式：
dotnet nuget list source dotnet nuget locals all --list第一条列出当前生效的包源，第二条会把全局包文件夹、HTTP缓存、临时目录的位置全部打出来。我习惯先把这些信息截图保存，后面改配置出问题时能快速对比。这里有一个容易被忽略的情况：VS2022里的包源列表和命令行看到的源可能不完全一样，因为VS会额外读取自己的配置，有时还会受“程序包源映射”功能影响。后面我会专门讲这个坑。
3.2 第二步：把全局包缓存改到共享目录
为什么要动全局包缓存？默认位置在C盘用户目录，C盘空间一旦吃紧，第一个背锅的就是它。另外，如果想在同一台机器的多个用户之间共享已下载的包，把缓存挪到一个公共目录会更合理。
改法有两种。第一种是设置环境变量NUGET_PACKAGES：
setx NUGET_PACKAGES "D:\NuGetShared\packages"设置完之后要重启终端和VS2022，环境变量才会生效。第二种是直接改用户级NuGet.Config：
<configuration> <config> <add key="globalPackagesFolder" value="D:\NuGetShared\packages" /> </config> </configuration>改完保存，重新打开VS2022，执行一次还原，NuGet会在新目录里重建包缓存。原有的旧缓存可以暂时不删，等确认所有项目都能正常构建之后再清理。这里要提醒一点：不要直接把旧缓存文件夹改名成新目录，以为能“继承”缓存。不同项目的缓存里可能会残留损坏的元数据，直接拷贝过去有时会让还原报错，干净重建反而更稳。
3.3 第三步：搭建本地文件夹源
本地文件夹源是最轻量的包共享方式。原理很简单：把一个目录当作NuGet源，目录里放.nupkg文件，NuGet客户端就能从这个目录还原包。
先在本地建一个目录，比如D:\NuGetLocalFeed。然后把想共享的包文件放进去。手动从网上下载或从全局缓存复制都行。我一般用PowerShell脚本从全局缓存批量导出，这样一条命令就能把当前机器上已还原的所有包都搬到本地源：
$sourceRoot = "$env:USERPROFILE\.nuget\packages" $destRoot = "D:\NuGetLocalFeed" $packageIds = Get-ChildItem $sourceRoot -Directory foreach ($idDir in $packageIds) { $versionDirs = Get-ChildItem $idDir.FullName -Directory | Where-Object { $_.Name -notlike '.*' } foreach ($verDir in $versionDirs) { $nupkg = Get-ChildItem $verDir.FullName -Filter "*.nupkg" | Select-Object -First 1 if ($nupkg) { $dest = Join-Path $destRoot $idDir.Name New-Item -ItemType Directory -Force -Path $dest | Out-Null Copy-Item $nupkg.FullName (Join-Path $dest $nupkg.Name) } } }脚本的逻辑是按“包ID/版本号”的目录结构去找.nupkg，再按同样的层级复制到目标目录。NuGet的本地源支持平铺目录，但按ID分文件夹后在VS的包管理器里浏览起来更清晰。
复制完成后，在VS2022的包源设置里点“添加”，名称填LocalFeed，源填D:\NuGetLocalFeed。命令行也可以：
dotnet nuget add source "D:\NuGetLocalFeed" -n "LocalFeed"之后对任何项目执行还原，NuGet会先从全局缓存找，找不到就按配置的源顺序去本地源找。只要本地源里有对应版本的包，即使离线也能还原成功。
3.4 第四步：离线环境下的包迁移
真正被逼着做NuGet共享的，多数是离线机器。步骤其实不复杂：在一台有网的机器上把需要的.nupkg全部收集好，拷贝到目标机器，然后在目标机器上把目录配置成本地源。上面那个PowerShell脚本已经可以完成“收集”这一步，但要确保收集了传递依赖。光收集主包文件通常不够，比如你引用了某ORM框架，它底层还依赖日志组件、连接驱动，这些传递依赖缺一个，还原就会抛NU1101或NU1103。
一个比较稳妥的做法是，在有网机器上打开目标解决方案，执行一次完整的dotnet restore，确认没有缺包，再用脚本把整个全局缓存里涉及的所有包全部导出，而不是只导出你认识的几个主包。这样虽然会多拷贝一些用不上的包，但能避免离线机器还原到一半发现缺包。拷贝介质用U盘、移动硬盘或者内网共享目录都可以，关键是把D:\NuGetLocalFeed完整拷过去，别只拷一部分。
目标机器上执行：
dotnet nuget add source "D:\NuGetLocalFeed" -n "OfflineFeed" dotnet restore如果项目设置了锁文件，还原会严格按锁文件里的版本去找包，本地源里如果没有对应版本，依然会失败。所以导出的包最好和锁文件版本完全一致。
3.5 第五步：用 Directory.Packages.props 锁定版本
共享缓存和本地源解决的是“从哪里拿包”的问题，但团队里每个人引用的包版本不一致的问题还没有根治。有人项目里写的是13.0.3，有人写的是13.0.1，还原出来行为当然不一样。VS2022对SDK风格项目支持“集中包管理”，也就是Central Package Management（CPM），这个功能强烈建议用起来。
做法是在解决方案根目录创建一个Directory.Packages.props文件：
<Project> <PropertyGroup> <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally> </PropertyGroup> <ItemGroup> <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" /> <PackageVersion Include="Serilog" Version="3.1.1" /> </ItemGroup> </Project>然后项目文件里的PackageReference就只写包名，不写版本：
<ItemGroup> <PackageReference Include="Newtonsoft.Json" /> <PackageReference Include="Serilog" /> </ItemGroup>这样整个解决方案的包版本都由根目录这一个文件管着，谁要升级版本，改这一处就行。它和本地源是互补关系：本地源保证能拿到包，中央包管理保证大家拿的是同一个版本。
3.6 第六步：团队层面统一配置
如果只想自己一个人用，前面几步已经够了。但给团队统一，最好把配置固化到代码仓库里。我会在解决方案根目录放一份nuget.config，内容类似下面这样：
<configuration> <config> <add key="globalPackagesFolder" value="D:\NuGetShared\packages" /> </config> <packageSources> <clear /> <add key="LocalFeed" value="D:\NuGetLocalFeed" /> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" /> </packageSources> </configuration>这里有个非常关键的操作，就是在packageSources节点里先用<clear />清掉所有继承来的源。不清的话，成员机器上如果有旧的、乱七八糟的源配置，还原时可能从奇怪的地方拉包，轻则慢，重则出安全问题。清掉之后再按需添加我们自己的源和nuget.org。
更激进的方案是开启“包源映射”（packageSourceMapping）。设置之后，可以指定哪些包只能从哪个源下载，避免因源顺序问题导致包被恶意替换。不过这功能配置门槛不低，初次尝试共享的用户可以先不开，等团队适应了再逐步收紧。
4. 常见问题与排查技巧实录
4.1 问题速查表
这次折腾过程中，我把遇到的高频问题整理成一张速查表，后面再处理同类问题可以照着看：
| 现象/错误 | 可能原因 | 处理办法 |
|---|---|---|
| NU1101 找不到包 | 源列表里没有对应包，或版本不匹配 | 检查源列表、补充对应版本的.nupkg |
| NU1103 找不到可满足版本的包 | 项目要求版本范围与本地源不一致 | 确认锁文件和Directory.Packages.props里的版本 |
| 还原突然变慢 | HTTP缓存被清、源顺序把公网放太靠前 | 检查http-cache路径，把本地源调整到最前 |
| 项目构建报projects.assets.json损坏 | 缓存被并发修改或文件损坏 | 删除对应包的缓存目录后重新还原 |
| 多人共用共享缓存目录时报文件占用 | 多进程同时写同一缓存目录 | 局域网场景避免直接共用NUGET_PACKAGES路径 |
| VS2022浏览标签页看不到本地源包 | 源未刷新、目录结构不对、包源映射限制 | 点刷新，检查目录下有.nupkg，检查映射规则 |
| 改了NUGET_PACKAGES但不生效 | 环境变量未刷新、被更高优先级配置覆盖 | 重启VS/终端，检查解决方案根目录的nuget.config |
4.2 几个典型的排查案例
第一个案例是“在我机器上能还原，新同事机器上不行”。排查下来发现新同事的VS2022里没有配置我们仓库里的nuget.config，还在用默认的nuget.org源。把解决方案根目录的nuget.config提交到仓库后，这个问题彻底消失，因为VS打开解决方案时会自动读取根目录配置，能保证每个成员用的源列表是一致的。
第二个案例更有意思，设置了NUGET_PACKAGES环境变量，但还原后包还是跑到了默认的.nuget\packages。排查过程是：先看环境变量有没有生效，发现setx之后终端没重启；重启后再还原，结果还是不对。最后定位到是解决方案根目录有一份旧版nuget.config，里面显式设置了globalPackagesFolder为默认值，它的优先级比用户级配置高，直接覆盖了环境变量。删除旧配置项后，新路径才生效。
第三个案例是离线机器上还原报NU1103，提示找不到版本。明明我已经把项目里引用的主包拷到本地源了，为什么还说缺？原因是该主包依赖的其他传递依赖包没有一起导过来。重新在有网机器执行完整还原后，用脚本导出全部全局缓存，再把整个本地源目录拷到离线机器，问题就解决了。这也是离线共享里最容易忽略的一环，传递依赖经常被漏掉。
4.3 我的几点避坑心得
实际踩过坑之后，我总结了几条经验，不一定写在官方文档里，但对做NuGet共享的人来说很有价值。
第一条，共享目录最好放在本机硬盘，不要直接把网络盘设成NUGET_PACKAGES。虽然理论上可以这样，但网络盘在还原大量包时会有严重的并发和延迟问题，多个开发者同时还原还可能因为文件锁导致缓存损坏。正确做法是每台机器本地维护一份缓存，通过共享盘里的本地源来分发包文件，还原时命中本地缓存才快。
第二条，清理缓存要克制。dotnet nuget locals all --clear这个命令很爽快，一下子把全局缓存、HTTP缓存全清了，但清完之后你要用的老版本包就得重新下载。如果离线环境里某个老版本已经很难找到，清缓存等于给自己挖坑。我一般只清理确认不用的包，或者干脆不动。
第三条，中央包管理比共享缓存更值得优先推行。缓存共享解决的是“拿包快不快”，版本锁定解决的是“构建结果一致不一致”。很多团队做共享只盯着缓存，版本其实早就乱套了。先把Directory.Packages.props用起来，再配本地源，效果会好得多。
这次尝试下来，我自己最大的感受是：NuGet的共享机制并不神秘，核心就是“缓存 + 源 + 版本策略”三个抓手。一个人开发，理解了全局缓存的位置就够用了；一个小团队，把本地源和nuget.config提交进仓库就能解决绝大多数问题；更大规模再考虑私有服务器，没必要一上来就上重方案。如果你刚接触VS2022的NuGet，建议先打开命令行执行一下dotnet nuget locals all --list，看看自己机器上到底缓存了什么，很多关于“共享”的直觉一下子就通了。
