正确命令应为 find / -xdev -type f -size +1G 2>/dev/null，因默认会遍历虚拟文件系统、目录及无权限路径，导致错误、卡顿或误报；-type f 限定普通文件，-xdev 防跨挂载点，2>/dev/null 屏蔽权限错误。
为什么直接 find / -size +1G 会出错
这条命令看起来直白，但几乎必然返回一堆错误、卡住、或列出一堆根本不是“大文件”的东西。原因很实在：find 默认不区分文件类型，-size 对目录也生效——而目录的“大小”只是它自身元数据占的几个块，和实际磁盘占用毫无关系；更糟的是，它会钻进 /proc、/sys 这类虚拟文件系统，把 /proc/kcore（显示几百 GB，但根本不在磁盘上）也当真文件报出来。
常见现象包括：终端刷屏报 No such file or directory、命令长时间无响应、结果里混着路径名而非文件、甚至触发 OOM Killer（尤其在低内存 VPS 上）。
- 必须加
-type f：只匹配普通文件，跳过目录、设备、符号链接 - 必须加
-xdev：不跨挂载点，避免进入/mnt/nas、/boot或容器 overlay 分区 - 建议加
2>/dev/null：屏蔽权限不足导致的报错，让结果干净可读
find 的 -size 单位和符号到底怎么算
-size 后面的值不是 MB/GB，也不是字节，而是带单位后缀的整数，且大小写敏感、符号决定逻辑——写错一个字母或符号，结果就差十倍。
-
+500M表示“严格大于 500 MiB”（即 500 × 1024 × 1024 字节），不是 ≥500MB -
-500M表示“严格小于”，500M是“精确等于”（基本没用，文件极少刚好对齐） - 单位只能是：
b（512 字节块，慎用）、c（字节）、k（KiB）、M（MiB）、G（GiB）——B不合法，mb小写也不认 - 想查“≥100MB”，别写
+100M，改用+99M更稳妥，避免漏掉 100.1 MiB 的文件
查完之后怎么知道哪个最大、要不要删
find 只能过滤，不能排序。光输出一堆路径，根本看不出谁吃空间最多。真正要定位“隐形巨无霸”，得靠 du 和 sort 配合。
- 查当前目录下前 10 个最大文件：
du -h * 2>/dev/null | sort -hr | head -n 10 - 查整个
/var下最大文件并按大小列清楚：find /var -xdev -type f -exec ls -lh {} \; 2>/dev/null | sort -rh -k5 | head -n 10（-k5指ls -lh输出的第 5 列，即大小字段） - 别直接
-delete：误删/var/log/journal/或 Docker 日志是高频事故。永远先-print或-ls预览，确认路径无误再操作
什么时候该换 du 而不是硬扛 find
如果目标不是“超过某个阈值”，而是“谁在偷偷吃掉磁盘”，find -size 就不够用了。比如硬链接共享 inode、稀疏文件、加密容器内部结构，这些都会让 find 漏判。
du 统计的是真实磁盘占用，find 看的是单个文件声明大小——两者在压缩、去重、快照等场景下差异巨大。
- 快速扫出最占空间的目录：
du -sh /* 2>/dev/null | sort -hr - 交互式探查（推荐装
ncdu）：ncdu /var，支持键盘导航、实时大小统计、安全删除 - 查日志类“活跃大户”，加
-mtime +7过滤旧文件，避开正在写的access.log：find /var/log -type f -size +100M -mtime +7
真正难的不是命令怎么敲，而是判断“这个大文件是不是还在被进程使用”——lsof +L1 或 lsof /path/to/file 才能确认，跳过这步直接删，服务就断了。
