1. 项目缘起：为什么我们需要关注NuGet的路径？

如果你是一个.NET开发者，无论是用Visual Studio还是dotnet CLI，NuGet包管理器几乎是你每天都要打交道的工具。它帮我们管理着项目依赖，让代码复用变得无比轻松。但不知道你有没有遇到过这样的困扰：随着项目越做越多，C盘的空间开始“告急”，那个名为.nuget的文件夹在用户目录下悄悄膨胀，动辄占用几十个GB的空间。或者，在搭建CI/CD流水线时，你发现构建服务器上的包缓存位置不对，导致每次构建都要重新下载，拖慢了整个流程。又或者，你只是想清理一下临时文件，却不知道哪些是NuGet的缓存可以安全删除，哪些是项目运行必需的。

这些问题，归根结底，都指向了NuGet的存储路径管理。默认情况下，NuGet会把全局包、HTTP缓存和插件缓存等，都放在用户目录下。对于个人开发机，这可能只是占用点C盘空间；但对于团队协作、服务器环境或使用固态硬盘（SSD）且容量紧张的情况，这就成了一个必须解决的工程问题。手动去AppData里删除文件夹是治标不治本，我们需要的是系统性地了解并掌控这些路径。

今天，我们就来彻底拆解NuGet的全局包、缓存和临时文件夹路径。这不仅仅是一次简单的“位置查询”，而是一次从原理到实践的深度配置之旅。我会带你弄清楚这些路径分别是什么、存了什么、为什么重要，以及最关键的一步——如何根据你的实际需求，安全、高效地迁移或清理它们。无论你是想释放C盘空间，还是优化团队构建环境，这篇文章都能给你一份可以直接“抄作业”的解决方案。

2. NuGet三大核心路径详解：它们各自管什么？

在动手修改任何路径之前，我们必须先搞清楚NuGet到底在哪些地方存了东西，以及这些东西的作用是什么。混淆它们可能会导致包无法正常恢复，甚至破坏开发环境。根据官方文档和实际行为，我们可以将NuGet的存储分为三个核心路径，它们的功能和重要性各不相同。

2.1 全局包文件夹 (global-packages)

这是最重要的路径，没有之一。你可以把它理解为你本地开发机器的“包仓库”。当你通过dotnet restore或Visual Studio的包还原功能安装一个NuGet包（例如Newtonsoft.Json 13.0.1）时，NuGet会首先检查这个全局包文件夹里是否已经存在该版本的包。如果存在，就直接从这里复制到你项目的obj目录和输出目录；如果不存在，则从配置的源（如nuget.org）下载，并同时存入这个全局包文件夹。

关键特性：

• 共享性：所有在你机器上的.NET项目共享这个仓库。安装过的包版本在这里只会存一份。
• 只读性（对用户而言）：你不应该手动修改这个文件夹里的内容。NuGet会管理它的结构。
• 持久性：一旦下载，包就会一直留在这里，除非你手动删除。这是它占用大量磁盘空间的根本原因。

默认位置：

• Windows:%USERPROFILE%\.nuget\packages(例如：C:\Users\你的用户名\.nuget\packages)
• Linux/macOS:~/.nuget/packages或~/.local/share/NuGet/Cache(取决于版本和配置)

这个文件夹的结构是层级化的，例如Newtonsoft.Json\13.0.1\，里面包含了包的.nupkg文件和解压后的内容。

2.2 HTTP缓存文件夹 (http-cache)

这个文件夹的作用是缓存NuGet与包源（如nuget.org）通信时产生的HTTP响应。这不仅仅包括包的二进制内容（这部分更主要的在全局包文件夹），还包括源目录、搜索结果的元数据等。它的主要目的是加速重复的查询操作，减少网络请求。

关键特性：

• 加速元数据查询：当你Visual Studio里搜索包，或者执行dotnet list package等命令时，这些元数据可能会被缓存到这里。
• 可安全清理：这里的缓存数据是可以被清理的，且不会影响已安装的包。清理后，下次操作会重新从网络获取。
• 有时与全局包文件夹合并：在较新的NuGet版本（特别是基于.NET SDK的工具链）中，HTTP缓存的概念可能被弱化，部分功能整合进了全局包文件夹的管理中。但作为一个明确的配置项，它仍然存在。

默认位置：

• Windows:%LOCALAPPDATA%\NuGet\v3-cache(例如：C:\Users\你的用户名\AppData\Local\NuGet\v3-cache)
• Linux/macOS:~/.local/share/NuGet/v3-cache

2.3 临时文件夹与插件缓存

这是一个相对宽泛的概念，NuGet在运行过程中还会使用一些临时位置。

• NuGet插件缓存：如果你使用了NuGet插件（某些高级场景），插件自身可能会产生缓存，其路径通常由插件定义或位于临时目录下。
• 操作临时目录：在解压包、执行包内脚本等操作时，NuGet会使用系统的临时目录（%TEMP%或/tmp）。

这些路径通常不需要我们主动去配置或迁移，但了解它们的存在有助于在排查问题时（比如磁盘空间被莫名占满）定位源头。我们关注的重点，是前两个——全局包文件夹和HTTP缓存文件夹。

3. 如何查看与修改这些路径？

知道了是什么，接下来就是怎么找到和改变它们。我们将分命令行和配置文件两种方式来操作。

3.1 使用命令行工具快速查看

最直接的方法是使用dotnet和nuget命令行工具。

查看全局包文件夹位置：

dotnet nuget locals global-packages --list

执行这个命令，它会输出当前生效的全局包文件夹路径。

查看所有本地资源（包括缓存）：

dotnet nuget locals all --list

这个命令会列出所有类型的本地资源路径，通常包括：

• global-packages： 全局包文件夹
• http-cache： HTTP缓存文件夹
• temp： 临时缓存文件夹
• plugins-cache： 插件缓存文件夹（如果存在）

使用旧版NuGet CLI：如果你安装了独立的nuget.exe，可以使用：

nuget locals all -list

3.2 通过环境变量进行全局修改（推荐）

这是最推荐、影响范围最广的配置方式。通过设置系统或用户级别的环境变量，可以让所有使用NuGet的工具（Visual Studio, dotnet CLI, MSBuild, nuget.exe）都遵循新的路径。

核心环境变量：

• NUGET_PACKAGES: 用于设置全局包文件夹的位置。
• NUGET_HTTP_CACHE_PATH: 用于设置HTTP缓存文件夹的位置。

操作步骤（以Windows为例，迁移全局包文件夹到D盘）：

1. 打开环境变量设置：

   • 在Windows搜索框输入“环境变量”，选择“编辑系统环境变量”。
   • 在打开的“系统属性”窗口中，点击“环境变量”按钮。

2. 新建用户变量（仅影响当前用户）或系统变量（影响所有用户）：

   • 在“用户变量”或“系统变量”区域，点击“新建”。
   • 变量名：NUGET_PACKAGES
   • 变量值：你想要设置的新路径，例如D:\NuGetCache\packages。

     注意：路径可以不存在，但你需要有该路径的读写权限。建议使用一个简单的、没有空格和特殊字符的路径。

3. 同样方法，可以设置HTTP缓存：

   • 变量名：NUGET_HTTP_CACHE_PATH
   • 变量值：例如D:\NuGetCache\v3-cache

4. 应用并重启：

   • 点击“确定”保存所有更改。
   • 至关重要：你必须关闭并重新启动所有已经打开的Visual Studio、命令行终端（CMD、PowerShell、Terminal），新的环境变量才会生效。

验证修改是否生效：打开一个新的命令行窗口，再次运行dotnet nuget locals global-packages --list，检查输出的路径是否已经变成了你新设置的位置。

Linux/macOS下的操作：在~/.bashrc,~/.zshrc或相应的shell配置文件中添加：

export NUGET_PACKAGES=/path/to/your/custom/packages export NUGET_HTTP_CACHE_PATH=/path/to/your/custom/http-cache

然后执行source ~/.bashrc或重新打开终端。

3.3 通过NuGet.Config配置文件进行精细控制

环境变量是全局的。如果你需要为特定的项目或解决方案设置不同的包路径，或者你的CI/CD服务器需要独立的配置，那么使用NuGet.Config文件是更灵活的选择。

NuGet会从多个位置读取配置，优先级从高到低为：

1. 当前目录（项目根目录）的NuGet.Config
2. 解决方案目录的NuGet.Config
3. 用户目录的NuGet.Config(%APPDATA%\NuGet\NuGet.Config或~/.nuget/NuGet.Config)
4. 机器全局的NuGet.Config(%ProgramFiles(x86)%\NuGet\Config或/etc/nuget/config)

在配置文件中修改全局包路径：打开或创建对应的NuGet.Config文件，添加或修改globalPackagesFolder设置：

<?xml version="1.0" encoding="utf-8"?> <configuration> <config> <!-- 设置全局包文件夹 --> <add key="globalPackagesFolder" value="D:\NuGetCache\packages" /> <!-- 设置HTTP缓存文件夹（旧版配置项，部分场景有效） --> <!-- <add key="httpCachePath" value="D:\NuGetCache\v3-cache" /> --> </config> </configuration>

重要提示：对于HTTP缓存，httpCachePath这个配置项在新版的基于SDK的NuGet中可能不被完全支持，环境变量NUGET_HTTP_CACHE_PATH通常是更可靠的方式。全局包路径的配置则两者皆可，且配置文件优先级高于环境变量（如果冲突）。

4. 迁移路径的完整操作流程与避坑指南

假设你现在C盘空间紧张，决定将全局包文件夹从默认的C盘用户目录迁移到D盘的一个新位置。这不仅仅是改个配置那么简单，你需要一个完整的、安全的操作流程。

4.1 迁移前的准备工作

1. 备份当前状态（可选但建议）：虽然迁移操作通常安全，但备份总是好习惯。你可以简单地将现有的%USERPROFILE%\.nuget文件夹复制到另一个位置。
2. 记录当前项目状态：确保你所有正在开发的项目都已经提交了代码更改，或者至少没有未保存的重要工作。关闭Visual Studio和所有命令行终端。
3. 规划新路径：选择一个有足够空间、读写权限简单的路径。例如：D:\Development\NuGet。避免使用网络路径或云盘同步文件夹（如OneDrive、Dropbox），这可能导致性能问题或文件锁定错误。

4.2 分步迁移操作

步骤一：设置新的环境变量如前文所述，在系统环境变量中设置NUGET_PACKAGES为新的路径，例如D:\Development\NuGet\packages。同时也可以设置NUGET_HTTP_CACHE_PATH。

步骤二：复制现有包缓存（可选，但能节省大量时间）这是迁移中最关键的一步，目的是避免所有项目重新下载所有包。

• 打开文件资源管理器，进入旧的全局包文件夹：%USERPROFILE%\.nuget\packages。
• 选中该文件夹内的所有内容（即所有以包名命名的文件夹）。
• 复制它们。
• 粘贴到新的全局包文件夹（例如D:\Development\NuGet\packages）中。如果目标文件夹不存在，请先创建。
• 等待复制完成。这个过程可能较长，取决于原有缓存的大小。

步骤三：验证与重启

1. 打开一个新的命令行窗口（这是为了确保新的环境变量已加载）。
2. 运行dotnet nuget locals global-packages --list，确认路径已更新。
3. 找一个已有的.NET项目，在其目录下运行dotnet restore --force。--force参数会强制重新评估所有依赖。
   • 理想情况：还原过程非常快，并且没有或只有极少的网络下载活动。这说明NuGet成功地从新位置找到了包。
   • 如果开始大量下载：检查复制过程是否出错，或者新路径的权限是否正确。可以尝试删除新路径下的内容，让NuGet重新下载，但这会消耗时间和流量。

步骤四：清理旧缓存（在确认一切正常后）确认所有项目都能在新路径下正常还原后，你就可以安全地删除旧的缓存文件夹以释放C盘空间了。

• 可以直接删除%USERPROFILE%\.nuget整个文件夹。
• 更稳妥的方法是使用命令行清理：

  # 清理旧的全局包缓存（在旧路径可能已失效，但执行无害） dotnet nuget locals global-packages --clear # 清理所有旧的本地缓存 dotnet nuget locals all --clear

  注意，这些清除命令会基于当前配置的路径进行清理。在环境变量生效后，它们清理的是新位置的缓存（如果你想清理的话）。要物理删除旧文件夹，还是需要手动操作。

4.3 常见问题与解决方案

问题1：迁移后，Visual Studio提示“找不到包”或还原失败。

• 排查：确保Visual Studio是在设置环境变量并重启电脑后才打开的。Visual Studio在启动时会读取环境变量，如果它是在设置前打开的，则不会生效。
• 解决：完全关闭Visual Studio，再重新打开。如果问题依旧，检查项目目录或上级目录是否有自定义的NuGet.Config文件覆盖了全局包路径。

问题2：复制包文件时，提示“文件正在使用”或“权限不足”。

• 排查：有程序正在使用这些包文件，可能是某个未关闭的Visual Studio实例、IIS Express、或者dotnet watch run等进程。
• 解决：关闭所有相关的开发工具和进程。如果是在Windows上，可以尝试重启资源管理器或直接重启电脑，再进行复制。

问题3：磁盘空间不足，无法复制。

• 解决：不要复制，直接采用“硬链接”方式（仅限Windows NTFS文件系统）。这可以几乎不占用额外空间，让新旧路径指向同一份数据。但操作复杂，且对后续清理有影响。对于大多数用户，更建议直接重新下载，或者先清理一部分不常用的旧包（见下一章）再复制。

问题4：团队开发时，如何统一配置？

• 方案：对于团队，建议将路径配置放在解决方案级别的NuGet.Config文件中，并将该文件提交到版本控制（如Git）。这样，任何克隆该仓库的成员，其NuGet行为都会自动统一。
  • 在解决方案根目录创建NuGet.Config。
  • 内容设置为指向一个团队约定的公共位置（例如一个共享的网络驱动器，但需注意性能和稳定性），或者就指向默认位置，但统一了清理策略。
  • 更常见的做法是，在CI/CD流水线（如Azure DevOps, GitHub Actions）的配置文件中，通过脚本设置环境变量NUGET_PACKAGES到一个可被缓存的位置，以加速后续构建。

5. 缓存清理策略与自动化维护

迁移路径解决了“放哪里”的问题，但缓存本身会无限增长。我们需要建立清理策略。

5.1 手动清理命令

dotnet nuget locals命令是你的主要清理工具：

# 清理全局包缓存（慎用，这会使后续还原需要重新下载） dotnet nuget locals global-packages --clear # 清理HTTP缓存（安全，只清理元数据） dotnet nuget locals http-cache --clear # 清理临时缓存（安全） dotnet nuget locals temp --clear # 清理所有本地缓存 dotnet nuget locals all --clear

警告：global-packages --clear会删除整个全局包文件夹。除非你确定所有项目的包都可以重新下载（且网络条件好），否则不要轻易在个人开发机上执行。在CI/CD服务器上，这通常是标准步骤，以确保构建的纯净性。

5.2 更精细的清理：使用nuget.exe或第三方工具

dotnet nuget locals --clear是“全有或全无”。如果你想清理特定旧版本的包，或者清理一段时间未使用的包，就需要更精细的工具。

• 使用nuget.exe:旧版的独立nuget.exe有一个locals命令，但功能类似。对于精细清理，社区有更多工具。
• 使用 PowerShell 脚本：你可以编写PowerShell脚本，遍历globalPackagesFolder，根据文件夹的最后访问时间，删除超过一定期限（比如180天）的包版本。这需要谨慎处理文件夹结构。
• 第三方工具：像NuGetCacheCleaner这样的第三方工具提供了图形界面或更多选项来管理缓存。使用前请评估其安全性和可靠性。

5.3 自动化维护脚本示例（Windows PowerShell思路）

这里提供一个思路，你可以创建一个PowerShell脚本，定期运行以清理过期的包缓存。执行前请务必在测试环境验证，并备份重要数据。

# 示例：清理超过90天未访问的包版本 $globalPackagesPath = $env:NUGET_PACKAGES if (-not $globalPackagesPath) { $globalPackagesPath = "$env:USERPROFILE\.nuget\packages" } $cutoffDate = (Get-Date).AddDays(-90) Get-ChildItem -Path $globalPackagesPath -Directory | ForEach-Object { # 每个包名文件夹，如 Newtonsoft.Json $packageName = $_.Name Get-ChildItem -Path $_.FullName -Directory | ForEach-Object { # 每个版本文件夹，如 13.0.1 $versionFolder = $_ $lastAccess = $versionFolder.LastAccessTime if ($lastAccess -lt $cutoffDate) { Write-Host "Deleting old package: $packageName $($versionFolder.Name) (Last accessed: $lastAccess)" # 取消下一行的注释以实际执行删除 # Remove-Item -Path $versionFolder.FullName -Recurse -Force } } } Write-Host "Cleanup analysis complete. Review the output above." Write-Host "To actually delete, uncomment the 'Remove-Item' line in the script."

这个脚本只会输出将要删除的内容，并不会真正执行删除。确认无误后，你需要取消Remove-Item行的注释。你可以将此脚本设置为Windows任务计划程序，每月自动运行一次。

5.4 针对CI/CD服务器的特别优化

在持续集成环境中，缓存管理是提升构建速度的关键。

1. 使用环境变量锁定路径：在构建代理上，将NUGET_PACKAGES设置到一个固定路径，例如D:\Agent\_work\_tool\NuGet\packages。
2. 启用缓存任务：现代CI/CD平台（如GitHub Actions, Azure Pipelines）都提供了“缓存”步骤。你可以缓存这个全局包文件夹路径。构建开始时，平台会尝试恢复缓存；构建结束后，会根据键值更新缓存。
   • GitHub Actions 示例：

   - name: Cache NuGet packages uses: actions/cache@v3 with: path: ~/.nuget/packages key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }} restore-keys: | ${{ runner.os }}-nuget-

   这个配置会根据项目文件(.csproj)的哈希值创建缓存键，项目依赖没变，就直接用缓存，极大加速还原。
3. 定期清理：在流水线中，可以配置一个定期（如每周）的清理任务，执行dotnet nuget locals all --clear，防止缓存无限增长。但要注意平衡清理频率和缓存命中率。

通过这一整套从查看、修改、迁移到维护的策略，你就能完全掌控NuGet的存储行为，让它更好地为你的开发效率和系统资源管理服务。记住，关键是根据你的使用场景（个人开发、团队协作还是服务器构建）来选择合适的配置和清理策略。