1. 项目概述：为什么需要移动NuGet全局包文件夹？

如果你是一位.NET开发者，尤其是使用Visual Studio或者.NET CLI进行日常开发，那么你的C盘空间可能正在被一个名为.nuget的文件夹悄悄吞噬。这个文件夹就是NuGet的全局包缓存，它默认位于C:\Users\[你的用户名]\.nuget\packages（Windows）或~/.nuget/packages（macOS/Linux）。随着项目越来越多，引用的包版本不断累积，这个文件夹轻松就能占用几十甚至上百GB的磁盘空间。

我最近就遇到了这个问题，一台256GB SSD的开发机，C盘频频告急，一查才发现这个全局包文件夹已经占了快80GB。这不仅仅是空间问题，当缓存文件夹过大时，NuGet的包解析、还原速度也会受到影响，尤其是在清理或重建解决方案时。将全局包文件夹迁移到空间更大的非系统盘（比如D盘或E盘），是一个一劳永逸的解决方案。这不仅能释放宝贵的C盘空间，有时还能因为磁盘I/O性能的差异带来更快的包操作体验。

这个过程的核心，就是修改一个名为globalPackagesFolder的配置项。它可以通过多种方式设置，从项目级到用户级再到机器级，灵活且强大。接下来，我将详细拆解几种主流且可靠的配置方法，并分享我在实际操作中踩过的坑和总结的最佳实践。

2. 核心配置方案解析与选型

修改NuGet全局包文件夹的位置，本质上是在修改NuGet的配置。NuGet的配置是层级式的，理解这个层级是选择正确方案的前提。

2.1 NuGet配置层级与优先级

NuGet会从多个位置读取配置文件（通常是NuGet.Config），并按以下优先级合并（后者覆盖前者）：

1. 机器级配置：适用于整台计算机的所有用户。路径通常为：
   • Windows:%ProgramFiles(x86)%\NuGet\Config\或%ProgramData%\NuGet\Config\
   • macOS/Linux:/etc/opt/nuget/config/或/usr/local/share/nuget/config/
2. 用户级配置：适用于当前操作系统用户的所有项目。这是最常用、最推荐的修改层级。
   • Windows:%AppData%\NuGet\NuGet.Config(即C:\Users\[用户名]\AppData\Roaming\NuGet\NuGet.Config)
   • macOS/Linux:~/.config/NuGet/NuGet.Config或~/.nuget/NuGet.Config
3. 解决方案级配置：位于解决方案（.sln文件）所在的目录。适用于该解决方案下的所有项目。
4. 项目级配置：位于项目文件（.csproj等）所在的目录。仅适用于当前项目。

注意：修改globalPackagesFolder属于环境级别的配置，强烈建议在用户级进行设置。这样，无论你打开哪个解决方案、哪个项目，都会使用新的包文件夹，管理起来最方便。在解决方案或项目级设置此值通常不是好主意，因为它会破坏团队协作的一致性（其他成员的路径可能不同）。

2.2 方案选型：命令行 vs. 手动编辑

主要有两种方式修改配置：

1. 使用nuget config命令（推荐）：这是最官方、最不容易出错的方式。NuGet CLI工具会自动处理配置文件的创建、格式和层级。
2. 手动编辑NuGet.Config文件：直接使用文本编辑器修改XML文件，需要对配置结构有一定了解，适合喜欢“掌控一切”的开发者。

两种方式最终效果一致。对于大多数开发者，我强烈推荐使用命令行方式，因为它更简单、更安全。手动编辑时，一个格式错误（比如标签未闭合）就可能导致整个配置文件失效，所有NuGet操作都会报错。

3. 实操步骤详解：三种主流方法

无论你选择哪种方式，请先决定好新的全局包文件夹路径。例如，我打算将其迁移到D:\NuGetCache。

3.1 方法一：使用 NuGet CLI 命令行工具（最通用）

这是最标准的方法，适用于任何环境（Visual Studio内外）。

步骤1：确认或安装 NuGet CLI首先，你需要确保系统安装了NuGet命令行工具。打开终端（CMD, PowerShell, bash等）。 输入以下命令检查版本：

nuget help

如果显示帮助信息，说明已安装。如果未安装，你有两种选择：

• 通过官网下载：从 nuget.org 下载独立的nuget.exe，并将其所在目录添加到系统的PATH环境变量中。
• 通过 .NET SDK 使用：如果你安装了 .NET 6.0 或更高版本的SDK，可以使用功能更强大的dotnet nuget命令替代nuget命令。两者在配置操作上基本兼容。

步骤2：设置用户级全局包文件夹在终端中，执行以下命令：

nuget config -set globalPackagesFolder=D:\NuGetCache -configfile %AppData%\NuGet\NuGet.Config

或者使用dotnet nuget：

dotnet nuget add source --name custom-global-packages D:\NuGetCache # 注意：add source 不是设置缓存路径的正确命令，上面仅为举例说明dotnet nuget用法。正确设置缓存路径应使用： dotnet nuget config --set globalPackagesFolder=D:\NuGetCache --configfile ~/.nuget/NuGet.Config

关键参数解释：

• -set globalPackagesFolder=D:\NuGetCache：设置配置项globalPackagesFolder的值为新路径。
• -configfile %AppData%\NuGet\NuGet.Config：明确指定将更改写入用户级配置文件。在PowerShell中，%AppData%需要替换为$env:APPDATA。在macOS/Linux下，路径为~/.config/NuGet/NuGet.Config。

步骤3：验证配置执行命令后，可以查看配置文件内容以确认：

nuget config -configfile %AppData%\NuGet\NuGet.Config

你会在输出的XML中看到类似这样的部分：

<configuration> <config> <add key="globalPackagesFolder" value="D:\NuGetCache" /> </config> </configuration>

步骤4：清理旧缓存（可选但建议）配置生效后，新下载的包会存放到新位置，但旧的缓存仍在C盘。你可以手动删除C:\Users\[用户名]\.nuget\packages文件夹来释放空间。一个更安全的方法是让NuGet自动清理，或者使用nuget locals all -clear命令（但注意，此命令会清空所有本地缓存，包括全局包和临时缓存）。

实操心得：使用nuget config命令时，务必加上-configfile参数明确指定用户级配置文件。如果不指定，在某些情况下，它可能会修改当前目录下的NuGet.Config（如果存在），导致配置未按预期生效到所有项目。

3.2 方法二：在 Visual Studio 中配置（适合VS用户）

如果你主要使用Visual Studio进行开发，可以直接在IDE内完成配置，无需接触命令行。

步骤1：打开NuGet配置管理器在Visual Studio中，点击顶部菜单栏的“工具(T)”->“选项(O)”。 在弹出的“选项”对话框中，在左侧导航树中找到“NuGet 包管理器”->“常规”。

步骤2：修改全局包文件夹路径在右侧的“常规”设置面板中，你会看到一项名为“程序包还原”或直接是“全局包文件夹”的设置（不同VS版本表述略有差异）。找到一个显示当前路径的输入框，旁边通常有一个“...”浏览按钮。 点击“...”按钮，选择你预先创建好的新文件夹（例如D:\NuGetCache），然后点击“确定”。

步骤3：确认与重启点击“选项”对话框底部的“确定”按钮保存更改。重要：为了使更改完全生效，你需要关闭并重新启动所有正在运行的Visual Studio实例。因为包管理器服务可能已经缓存了旧的路径。

注意事项：Visual Studio的这个界面本质上也是在帮你修改%AppData%\NuGet\NuGet.Config文件。你可以用方法一中的验证命令查看，会发现文件内容已经被更新。这种方法直观，但隐藏了配置文件的细节。

3.3 方法三：手动编辑 NuGet.Config 文件（终极控制）

如果你喜欢直接操作配置文件，或者需要设置更复杂的配置（如结合多个源和凭证），可以手动编辑。

步骤1：定位并打开用户级配置文件导航到用户级配置文件的路径：

• Windows:C:\Users\[你的用户名]\AppData\Roaming\NuGet\NuGet.Config
• macOS/Linux:~/.config/NuGet/NuGet.Config或~/.nuget/NuGet.Config

如果该文件或目录不存在，可以手动创建。

步骤2：编辑XML内容用任何文本编辑器（如VS Code、Notepad++）打开NuGet.Config文件。其内容是一个标准的XML。 你需要确保<configuration>节点下存在<config>节点，并在其中添加或修改globalPackagesFolder项。一个完整的最小化示例如下：

<?xml version="1.0" encoding="utf-8"?> <configuration> <!-- 其他配置节，如packageSources --> <config> <!-- 添加或修改这一行，key必须为globalPackagesFolder --> <add key="globalPackagesFolder" value="D:\NuGetCache" /> </config> </configuration>

步骤3：保存并验证保存文件。之后，你可以通过命令行nuget config或在Visual Studio中查看选项来验证是否生效。

踩坑记录：手动编辑时最常见的错误是XML格式错误，例如标签未正确闭合、使用了错误的引号、或者将配置项放错了节点位置（例如误放入<packageSources>内）。编辑前建议备份原文件。如果配置后NuGet功能异常，首先检查这个文件的XML格式是否正确。

4. 迁移现有缓存与清理策略

仅仅修改路径，并不会自动将C盘已有的包移动到新位置。新下载的包会去新家，但旧包还留在原地。

4.1 是否要迁移旧缓存？

这是一个权衡：

• 迁移的好处：所有包在一个位置，管理方便。对于网络环境不好或包非常大的情况，可以避免重复下载。
• 不迁移的好处：操作简单。旧的缓存会随着时间推移，在你切换分支、升级项目Target Framework等过程中被逐渐淘汰和遗忘，你可以定期手动清理C盘的旧文件夹。

对于个人开发者，如果C盘空间不是极度紧张，我通常建议不进行物理迁移，而是采用“自然淘汰+定期清理”的策略。因为迁移过程如果出错，可能导致项目引用混乱。

4.2 如何安全清理旧缓存？

如果你决定清理C盘的旧缓存，请遵循以下步骤：

1. 确保所有Visual Studio实例和命令行终端都已关闭。
2. 备份重要项目（虽然此操作一般安全，但备份是好习惯）。
3. 直接通过文件资源管理器删除文件夹C:\Users\[用户名]\.nuget\packages。
4. 重新打开你的解决方案。Visual Studio或dotnet restore会重新下载项目所需的包到新位置。

你也可以使用NuGet自带的清理命令，但务必谨慎：

# 清除全局包缓存 nuget locals global-packages -clear # 清除所有本地缓存（包括global-packages, http-cache, temp等） nuget locals all -clear

使用-clear命令会立即删除缓存，请确保你了解其后果。

4.3 自动化清理脚本（进阶）

对于追求效率的开发者，可以创建一个简单的PowerShell或Shell脚本，在每次关闭电脑或定期运行时，删除超过一定天数未访问的包。这需要用到文件系统的“上次访问时间”属性。不过，请注意，过度激进的清理可能会在你离线工作时带来不便。

一个简单的PowerShell示例（谨慎使用，请先在小目录测试）：

# 定义旧缓存路径 $oldCachePath = "$env:USERPROFILE\.nuget\packages" # 删除30天未访问的文件和空目录 Get-ChildItem -Path $oldCachePath -Recurse -File | Where-Object {$_.LastAccessTime -lt (Get-Date).AddDays(-30)} | Remove-Item -Force # 清理空文件夹（需要递归多次） do { $dirs = Get-ChildItem -Path $oldCachePath -Recurse -Directory | Where-Object { (Get-ChildItem -Path $_.FullName -Force) -eq $null } $dirs | Remove-Item -Force -Recurse } while ($dirs.Count -gt 0)

5. 常见问题与排查技巧实录

在实际操作中，你可能会遇到一些问题。下面是我总结的常见问题及其解决方法。

5.1 配置不生效的排查流程

你修改了路径，但包似乎还是下载到了C盘。请按以下顺序排查：

1. 检查配置文件位置和优先级：运行nuget config all可以列出所有生效的配置源及其路径。确认你的globalPackagesFolder设置出现在最终合并的配置中，并且其值是正确的。有时，解决方案目录下的NuGet.Config会覆盖用户级设置。
2. 检查路径格式和权限：
   • 路径格式：确保路径是绝对路径，并且使用正确的分隔符（Windows用反斜杠\或正斜杠/均可，但建议使用\）。路径中不要包含未转义的特殊字符或空格（如果必须有空格，请用双引号包裹整个路径值，但在XML属性中，需要将双引号实体化为"，这很麻烦，所以强烈建议路径中不要有空格）。
   • 文件夹权限：确保当前用户对新文件夹路径有完全控制的读写权限。右键文件夹 -> “属性” -> “安全”选项卡，检查你的用户或所在的用户组（如Users）是否有“修改”和“写入”权限。如果没有，点击“编辑”添加权限。
3. 重启所有相关进程：修改配置后，必须关闭并重启Visual Studio、VS Code以及任何正在运行的dotnet命令终端。这些进程在启动时加载了旧的配置，不重启不会生效。
4. 检查环境变量（罕见情况）：有一个名为NUGET_PACKAGES的环境变量，如果设置了，它的优先级会高于配置文件中的globalPackagesFolder。检查你的系统或用户环境变量中是否设置了此变量。如果有，要么删除它，要么将其值修改为你的新路径。

5.2 路径包含空格或特殊字符的处理

正如前面提到的，路径中包含空格是万恶之源。虽然技术上可以通过在XML属性值中使用"包裹带空格的路径来实现，但这极易出错。

<!-- 不推荐！极易出错 --> <add key="globalPackagesFolder" value="&quot;D:\My NuGet Cache&quot;" />

最佳实践是：永远为你的开发环境相关路径（包括代码仓库、工具缓存等）创建没有空格和特殊字符的目录名。例如，使用D:\DevCache\NuGet而不是D:\My Projects\NuGet Cache。

5.3 团队协作与持续集成（CI）环境中的配置

在团队项目中，你不应该将globalPackagesFolder的设置提交到解决方案的NuGet.Config文件中。因为每个开发者的磁盘布局不同（有人C盘大，有人D盘大），强制一个路径会导致其他成员无法正常工作。

正确的做法是：每位开发者根据自己的机器环境，在用户级进行配置。团队仓库中的NuGet.Config只应包含包源（packageSources）、包版本管理（packageManagement）等与项目本身相关的、需要统一的配置。

对于CI/CD流水线（如Azure DevOps, GitHub Actions, Jenkins），同样需要在构建代理上配置。这通常通过以下方式之一：

• 在构建脚本中设置环境变量：在构建任务的第一步，设置NUGET_PACKAGES环境变量指向一个具有足够空间的磁盘路径。

  # GitHub Actions 示例 env: NUGET_PACKAGES: ${{ runner.workspace }}/.nuget/packages

• 在构建代理上预配置用户级NuGet.Config：如果是自托管代理，可以像配置本地机器一样，为运行代理服务的账户配置用户级缓存路径。

5.4 性能影响与磁盘选择

将全局包文件夹移动到更快的磁盘（如NVMe SSD）理论上可以提升包还原和项目加载速度。但通常来说，从SATA SSD移动到NVMe SSD的感知提升可能不如从HDD移动到SSD那么明显。更重要的因素是确保目标磁盘有充足的剩余空间（建议至少保留20%以上），因为磁盘空间不足会严重影响性能并导致各种奇怪错误。

如果你使用的是机械硬盘（HDD），强烈建议将其迁移到固态硬盘（SSD），这对整体开发体验的提升是巨大的。

6. 高级配置：结合符号链接的“无损”迁移

对于已经饱受C盘空间困扰，又不想等待旧缓存自然淘汰，或者希望“无缝”迁移所有现有包的用户，可以结合使用“目录联接”（Junction）或“符号链接”（Symbolic Link）。这个技巧非常实用，但操作需要谨慎。

原理：我们不直接修改NuGet配置，而是让系统认为包还在C:\Users\...\.nuget\packages，但实际上这个文件夹是一个“链接”，它指向了D盘的真实物理位置。

操作步骤（Windows，使用管理员权限的命令行）：

1. 关闭所有可能访问NuGet缓存的程序（VS, VS Code, 终端）。
2. 将原文件夹移动到新位置：

   robocopy "C:\Users\[用户名]\.nuget\packages" "D:\NuGetCache" /E /MOVE

   /E复制所有子目录（包括空目录），/MOVE移动文件并删除源文件。
3. 创建目录联接：

   mklink /J "C:\Users\[用户名]\.nuget\packages" "D:\NuGetCache"

   /J参数创建目录联接。执行成功后，你会发现C盘下的packages文件夹图标有一个快捷方式的小箭头，但它对应用程序来说就是一个普通文件夹。
4. 验证：打开新的命令行或VS，尝试还原一个项目。一切应正常工作，并且文件实际存储在D盘。

优缺点分析：

• 优点：对NuGet和所有开发工具完全透明，无需修改任何配置。实现了真正的“无损”和“即时”迁移。
• 缺点：
  • 需要管理员权限。
  • 如果链接创建失败或目标文件夹权限不对，会导致所有NuGet操作失败。
  • 在备份或磁盘清理时，需要特别注意这种链接关系。

重要警告：不要尝试手动在文件资源管理器中通过“剪切-粘贴”然后“创建快捷方式”来模拟此操作。mklink /J创建的目录联接与快捷方式（.lnk）有本质区别，大多数程序无法正确解析指向目录的快捷方式。