查大文件首选find，但必须加-type f和-xdev，否则会混入目录、符号链接及/proc等虚拟文件；+500M表示严格大于500MiB，单位区分大小写，B非法；真正占空间最多的文件需配合du -h | sort -hr定位。
直接用 find 查大于 100MB 的文件，不加限制大概率会卡住、报错、甚至误删关键系统文件——必须带 -type f、-xdev 和 2>/dev/null。
为什么 find / -size +100M 几乎总是错的
这条命令看着简洁，但实际运行时会：刷屏输出一堆 No such file or directory；卡在 /proc/kcore 这类虚拟文件上（它“显示”几百 GB，但根本不占磁盘）；把目录也当文件算大小（目录的 -size 是元数据块数，不是真实占用）；跨挂载点钻进 NFS、Docker overlay 或 /boot 分区，导致结果不可信或权限爆炸。
真正可用的最小安全组合是：
-
-type f：只匹配普通文件，跳过目录、设备、符号链接 -
-xdev：不跨挂载点，避免进入/mnt、/boot、容器层等非根文件系统 -
2>/dev/null：屏蔽Permission denied类报错，让输出干净可读
find 中 -size +100M 的单位和边界陷阱
+100M 表示“严格大于 100 MiB”（即 > 100 × 1024 × 1024 字节），不是 ≥100 MB。如果某个日志正好是 100.1 MiB，它会被命中；但如果是 100.0 MiB，就漏掉了。
常见错误写法：
-
+100MB：单位B不合法，find直接忽略该条件 -
+100mb：小写mb不识别，等同于没写 -
+100m：小写m在部分 BSD 系统中可能失效，GNU find 要求大写M
想覆盖“≥100MB”的场景，更稳妥写法是 +99M；单位只认：b（512 字节块）、c（字节）、k（KiB）、M（MiB）、G（GiB）。
查完怎么知道哪个最大？find 本身不排序
find 只过滤，不排序、不统计。光列出一堆路径根本看不出谁吃空间最多。要定位“真·巨无霸”，得靠组合：
- 查当前目录下前 10 个最大文件：
du -h * 2>/dev/null | sort -hr | head -n 10 - 查
/var下大于 100M 的文件并按大小倒序：find /var -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -rh -k5 | head -n 10（-k5指ls -lh输出的第 5 列，即大小字段） - 别直接
-delete：/var/log/journal/、/var/lib/docker/overlay2/下的文件一删就服务瘫痪，永远先-print或-ls预览
替代方案：du 更适合找“隐藏大户”
如果目标不是单个超大文件，而是发现某目录突然膨胀（比如 /var/log 占满），du 比 find 更合适：
-
du -ah /var/log | sort -hr | head -20：列出/var/log下所有文件+目录，按大小倒序取前 20 -
du -sh /var/* 2>/dev/null | sort -hr | head -10：只看/var一级子目录总大小 - 想交互式浏览，装
ncdu：ncdu /var/log，方向键导航，d删除确认，比纯命令更防手滑
真正容易被忽略的点是：查大文件不是“执行一条命令就完事”，而是先缩范围（比如只查 /var/log 而不是 /），再加防护（-xdev、-type f），最后才排序验证——漏掉任意一环，结果就不可信。
