【解决方案】Windows OS 系统盘清理，拒绝应用无限制占用 C 盘（配置/缓存/数据/预训练模型）

Windows 有多磁盘管理，但许多程序为了节省上行带宽流量，缓存的数据体积会随使用频率渐进增加，直到占据系统盘大量的空间，此时操作系统在运行时，可能会将内存分配到其他盘符，或其他物理硬盘，

内存是块状的，如果运行时内存过于分散，在多个硬盘间进行读写再整合这些比特，就会造成人们常说的系统卡顿。

有些程序提供了明显的修改入口，而大部分没有。这些数据大多数情况作为缓存，删除并不会导致程序崩溃，但程序的某些功能和用户设置可能会在下次运行时重置，或者运行时重新拉取数据带来一定滞后性，

而程序通常会在硬盘中重新写入数据，例如几十个 GB 的微信聊天记录，十几个 GB 的腾讯文档本地缓存，云空间带给了用户便携，却也带来了安全和隐私的隐患。

其实我们其他硬盘的存储空间往往很充分，也可以享受到最好的用户体验，也就引出了这篇文章。

缓存和配置文件

硬盘清理工具并不会将其识别为需要清理的对象，它无法准确判断清理目标是否会影响程序的用户体验，它本应交由每个程序自身进行管理。

但并不是每个产品设计时都能妥善考虑这部分功能，或者引导用户修改它的存储路径，最终的结果往往超出用户期待。

比如， Rust 语言的 cargo，和 Node.js 的 npm，短期使用下，仍会产生 n GB 体积的缓存文件，无论是冷缓存或是热缓存，这些文件对用户的开发效率至关重要。

程序的存储路径设置

以 微信 PC 端 举例，在 2025 年 7 月 4.0 版本之前还是 JS 与 Webview 架构的时候，所有的 聊天数据.dat 及 静态文件会默认存储在 C 盘，但它在设置页中提供了存储路径的修改选项。

如果某些程序未提供设置入口，我们则需要利用工具或手动检索 C 盘，主要在 C:\Users\User\AppData 目录。

不合预期的安装路径

许多程序非常占用硬盘，这取决于早期技术的历史积累和鲁棒性等原因，并没有考虑硬盘占用的优化。为了获取更高的执行权限，程序往往会默认安装在用户的系统盘。

如果用户在安装时忽略这点，之后的 mv 操作将会引入更多问题，比如环境变量失效导致程序无法运行，任务栏 / 开始菜单 / PowerToys Run 等快捷启动程序 的目标丢失。

对于快捷方式

我们需要重新创建它，或者在启动程序中重新注册，比如释放失效的快捷方式后将程序最新路径的可执行文件重新固定在任务栏等快捷程序中。

对于环境变量

以管理员方式启动 PowerShell，用旧版微信默认的数据存储路径 C:\Users\User\AppData\Local\WeChat 举例，

执行命令：

Get-ChildItem -Path Env: | Where-Object { $_.Value -like "*\AppData\Local\WeChat*" }

如果没有任何输出，表示该路径未注册在环境变量，如果它输出以下内容：

Name                           Value
----                           -----
Path                           ...其他环境变量路径...;C:\Users\User\AppData\Local\WeChat;...其他环境变量路径...
WECHAT                         C:\Users\User\AppData\Local\WeChat\bin

我们就需要把所有符合的环境变量改为程序最新对应的路径，

记住，如果不修改对应环境变量，你的软件可能会无法正常运行。

更安全的方式 —— Symbolic Link（符号链接）

符号链接就像文件夹的快捷方式，它们都可以跨盘符，不同的是，快捷方式.lnk 非 NFTS 内置机制。

Symbolic Link 谁在用？

• Windows 的包管理工具 scoop (kinda like HomeBrew in Mac) 使用它索引 apps 的不同应用版本，基于此特性我们可以随时下载应用的任何旧版本，在新版本和旧版本间随时切换
• Windows 的 Node 版本管理工具 nvm 使用它切换当前使用的 node 和 npm 版本 (Volta 也很好，但更利于社区而非企业)

符号链接 & 快捷方式 difference

当我们为目录创建一个快捷方式，它会生成一个 几百 kb 的 .lnk 文件，符号链接则会创建一个 0 kb 的 .symlink 文件。

在文章主题的场景中，通俗来说，lnk 为用户服务，而 symlink 为用户与程序服务：

* lse 是博主为命令 eza -lhr --git --git-ignore -s modified 设置的别名，类同于 ls 但对 Symbolic Link 的展示更直观。

显而易见，当程序通过 Symbolic Link 操作文件时，它能获取到相应硬盘中的物理位置，并保持在 symlink 的盘符与路径下，

相反 Shortcut 则不行，程序无法直接操作一个 lnk 文件，或读写它所指向目录的内部文件。

拿 Google Developers 分发的 cwebp 编码器执行文件举例，博主为它创建了一个 Shortcut，并将它的名字改为看起来可执行的 cwebp.exe：

正如先前所说，程序无法操作一个 lnk 文件。

创建符号链接

需要我们以管理员权限打开 PowerShell，执行以下命令：

New-Item -ItemType SymbolicLink -Path [destination] -Target [source]

拿微信举例，我们主动将 C:\Users\User\AppData\Local\WeChat 拷贝至期望目录，如 D:\Tools\WeChat，

则我们需要执行：

New-Item -ItemType SymbolicLink -Path C:\Users\User\AppData\Local\WeChat -Target D:\Tools\WeChat

完成后，数据仍然会存储在 D 盘符的硬盘物理地址中，正如我们期望，而 C 盘符会多出一个功能相同的 入口，

假如数据体积 100 GB，它会占用在 D 盘符，而对 C 盘符占用 0 字节，如此我们便释放了 C 盘符 100 GB 的硬盘占用。

这种方式无论对缓存数据和程序根目录本身都有效。

Symbolic Link 的副作用

我们通过 GUI 将目录从物理意义中 mv 操作后，如果文件夹内部本身存在 Symbolic Link，它们会消失。

我和其他许多在 Windows OS 中开发的用户一样，喜欢用 Chocolatey / Scoop 代替 Mac OS 中使用 Homebrew 的操作习惯，

拿 Scoop 举例，由于程序发布存在多版本管理问题，Scoop 会将程序最新版本链接到程序根目录的 current 下：

当我们将 scoop 目录路径移动后，current 的符号链接会消失，但使用这种技术的程序通常会提供 reset 工具，我们就可以通过脚本做一些批量操作，

假如你会用 Bash，执行以下命令即可重置 scoop 已安装程序的 Symbolic Link：

scoop list | awk '{print $1}' | tail -n +5 | grep -v '^$' | xargs -I {} scoop reset {}

实际上大多数包管理工具并不会使用这项技术，使用符号链接的程序开发者更为罕见，但我仍推荐用户对一个大型目录进行 mv 操作之前，检查内部是否含有符号链接，

或者在 mv 后产生程序崩溃，定位问题时考虑这一可能性。

递归检索已存在的 Symbolic Link

在 Powershell 中执行：

# 递归查找当前目录下所有符号链接（文件+目录通用，无遗漏）
Get-ChildItem -Path . -Recurse -Force -ErrorAction SilentlyContinue | 
Where-Object {
    # 核心条件：是重解析点（符号链接的本质）+ 能获取到目标路径（排除无效重解析点）
    $_.Attributes -match 'ReparsePoint' -and 
    $null -ne $_.Target  # 确保是有效符号链接（避免其他类型重解析点）
} | Select-Object FullName, LinkType, Target  # 显示关键信息（自身路径+类型+目标路径）

如果你想检索某个指定的目录而不用 cd 命令，可以将 -Path 参数的值修改成当前目录的相对路径/绝对路径，例如：

# 指定 D 盘符下的 scoop 目录
Get-ChildItem -Path "D:\scoop" -Recurse -Force -ErrorAction SilentlyContinue

如果它返回为空，则代表没有 Symbolic Link，否则返回 Symbolic Link 对应的绝对路径。

结语

通过符号链接我们可以释放数据不符预期的磁盘占用，它对用户和程序来说功能几乎相同，相应的它也存在一定的副作用。

记住，一旦当我们创建了符号链接，我们就需要考虑后续操作的维护工作。