大文件在哪里查看，资源管理器 size 语法为什么常漏掉最大那个

在资源管理器里搜 size:gigantic，C 盘只找出 6 个文件，加起来 11 GB，可实际占用是 190 GB。

这台是 win10，网上翻出来的教程几乎清一色在教这个搜索语法；机器上原先装的那个扫描工具，结果里最大的一项也只有 4 GB。两边漏掉的是同一批东西。

我换了个扫法重新过了一遍，排第一的单个文件 32 GB，资源管理器根本没列出来。网上的教程几乎全都在推荐这个搜索语法——而它有三个盲区，恰好覆盖了最占地方的那些文件。

先说这个语法怎么用

资源管理器右上角的搜索框支持体积筛选：

也可以直接写数值：size:>1GB、size:500MB..2GB。搜完点「大小」那一列排序，就是一份从大到小的清单。

配合别的条件也很好用：size:>1GB datemodified:<2024/01/01 能筛出「大且很久没动过」的文件，这类往往是最该处理的。

盲区一：隐藏文件和系统文件默认不搜

C 盘上最大的那几个文件，几乎全是隐藏的系统文件：pagefile.sys、hiberfil.sys、swapfile.sys、还有 MEMORY.DMP。

默认设置下，搜索不会返回它们。要看到，得先在「查看 → 选项 → 查看」里勾上「显示隐藏的文件、文件夹和驱动器」，再取消勾选「隐藏受保护的操作系统文件」。第二项系统会弹一个警告，确认即可。

开头那台机器上 32 GB 的那个文件就是完整内存转储，一直藏着。

盲区二：权限不足的目录会被跳过

C:\Windows\Installer、C:\System Volume Information、C:\ProgramData 下面部分目录，普通用户权限进不去。搜索遇到这些目录会静默跳过，不给任何提示。

而 Installer 恰恰是最容易膨胀的目录之一，我见过 100 GB 的。它里面全是几十 MB 到几百 MB 的小文件，单个不够 gigantic 的门槛，加起来吓人。

盲区三：它只看单个文件，不看目录累计

这是最根本的一条。C 盘上真正的占用大头，往往并非某一个巨大的文件，而多半是几万个小文件堆成的目录：浏览器缓存、包管理器缓存、聊天软件的图片、AppData 下的各种数据。

举个具体的例子。一个装了几十个插件、开着两个配置文件的 Chrome，User Data 目录能有 12 GB，里面文件数量以十万计，单个最大的可能才几十 MB。同样的道理适用于 npm 和 pip 的包缓存、微信几年积累下来的图片、以及 AppData\Local 底下那几十个软件各自的缓存目录。

这类占用有个共同特征：它们是慢慢长出来的，没有任何一个时刻会引起你的注意。 而巨大的单个文件反而容易被发现——下载一个 30 GB 的镜像，你自己是知道的。

这些目录里可能一个超过 128 MB 的文件都没有，按 size:gigantic 搜，一条结果都不会出来。而它们加起来能占几十个 GB。

该怎么看

想看清楚，需要的是按目录累计体积排序，而不是按单个文件大小筛选。

命令行能做一个粗版本：

Get-ChildItem C:\ -Directory -Force -ErrorAction SilentlyContinue | ForEach-Object {
    [PSCustomObject]@{
        Dir = $_.FullName
        GB  = [math]::Round((Get-ChildItem $_.FullName -Recurse -File -Force `
              -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum / 1GB, 2)
    }
} | Sort-Object GB -Descending | Select-Object -First 15

它会跑几分钟，而且遇到没权限的目录同样会跳过（-ErrorAction SilentlyContinue 把错误吞了），但至少能看到目录级的累计。要往下钻，把路径换成上一层的结果继续跑。

一次靠得住的扫描要满足三个条件：以管理员权限跑、把隐藏文件和系统文件一并计入、出的是目录和文件混合的累计排序而且能逐层展开。前面三个盲区就是这么绕开的——同一台机器上两种方法差出 179 GB，差的全在这三件事上。

那 190 GB 最后是谁

扫完的排序是这样的：完整内存转储 32 GB、Installer 目录 28 GB、微信的接收文件 26 GB、浏览器缓存和用户数据 19 GB、包管理器缓存 17 GB、休眠文件 12 GB、还原点 11 GB、其余分散在几十个软件目录里。

这八项里，只有内存转储一项能被 size:gigantic 搜到。其余七项要么是隐藏的、要么在没权限的目录里、要么是小文件堆出来的。

所以那个搜索语法本身没错，它只是回答了一个不同的问题——「有没有特别大的单个文件」。而 C 盘满了的时候，你要问的是「空间都去哪了」，这是两回事。

什么时候用哪个

两种方法各有各的场合，不必二选一。

知道自己下载过大东西、想找出来删掉，用 size:gigantic 最快，敲一行就出结果，不用装任何东西，也不用等几分钟的扫描。找旧的系统镜像、下载完忘了删的安装包、录屏软件留下的视频，这个语法很好用。

完全不知道空间去哪了，就得用目录累计排序。这是 C 盘报满时的标准第一步，跳过它直接照着通用教程删东西，很容易花两小时清出 3 GB。

我的习惯是先跑一遍目录排序看清楚全局，锁定几个可疑目录之后，再进到那个目录里用体积搜索找具体文件。先粗后细，比一开始就纠结单个文件有效率得多。