find是最可控的大文件定位方式，支持-size +xm等精确阈值筛选，需加-xdev避免跨文件系统、2>/dev/null屏蔽权限错误，单位区分大小写，-ls比xargs更安全处理特殊路径。
用 find 按大小精准筛选文件
直接定位大于某个阈值的文件，find 是最可控的方式。它不依赖缓存、不扫描无关目录，适合排查日志、core dump、临时备份等典型大文件来源。
常见错误是漏掉权限或挂载点限制：比如在根目录下执行 find / -type f -size +1G，会因权限不足中断、或误入 /proc /sys 等虚拟文件系统导致报错甚至卡死。
- 加
-xdev限定当前文件系统（避免跨分区/挂载点） - 加
2>/dev/null屏蔽权限拒绝的报错行，防止干扰结果 -
-size +100M表示“严格大于 100MB”，单位支持c(字节)、k、M、G；注意+500k不等于+500K（大小写敏感） - 若需同时显示大小，接
-ls（比-print | xargs ls -lh更安全，不惧空格/换行符）
示例命令：find /var/log -xdev -type f -size +50M -ls 2>/dev/null
用 du + sort 快速定位“真正吃空间”的文件
du 统计的是实际磁盘占用（含稀疏文件、硬链接计数等），比 find -size 更反映真实压力。但默认会把目录也列出来，容易误判——你看到一个 2GB 的目录，未必意味着里面有个 2GB 文件。
关键在加 -a（all files）和过滤类型：
-
du -ah /home | sort -hr | head -n 20：列出所有文件+目录，按人类可读大小倒序，取前 20。但结果混杂，需人工识别filevsdir - 更准的做法是先用
find找出所有普通文件，再交给du统计：find /home -xdev -type f -print0 | du -h --files0-from=- | sort -hr | head -n 20 -
--files0-from=-支持 null 分隔，能正确处理含空格、换行的路径，比xargs可靠
注意：du -sh * 这类写法只查当前层，且通配符会被 shell 展开，遇到几千个文件时可能触发 “argument list too long” 错误。
为什么 ls -lS 不适合找“系统级”大文件
ls -lS 确实能按大小排序当前目录下的文件，但它只读取目录项的 st_size 字段，对以下情况完全失效：
- 符号链接：显示的是链接字符串长度，不是目标文件大小
- 稀疏文件：
st_size是逻辑大小，du才是实际磁盘块占用 - 硬链接：多个路径指向同一 inode，
ls会重复计算，du默认去重（除非加-l） - 无法递归：
ls -lSR虽支持递归，但输出无统一排序，head截断后可能漏掉深层子目录里的真正大文件
所以它只适合快速扫一眼当前目录，别拿它查 /var 或 /home 这种深度结构。
权限、性能与易忽略的陷阱
真正跑起来才发现问题往往不在命令本身，而在环境约束：
- 非 root 用户执行
find /会大量报Permission denied，不仅干扰输出，还拖慢速度——必须加2>/dev/null或改用sudo（但 sudo 后的管道权限不继承，得整个包进sh -c） -
du /类操作可能耗时数分钟，期间磁盘 I/O 压力明显；生产环境建议避开高峰，或先限定路径如/var/home - 某些文件（如正在写的日志、数据库文件）
du和ls显示大小可能瞬时不一致，这是正常现象，不用反复刷新确认 - 别依赖
locate查大文件——它的数据库只存路径，不存大小，locate bigfile根本不知道它有多大
最常被跳过的一步：确认文件系统是否启用了配额（quota）或有隐藏快照（如 btrfs subvolume snapshot），这些也会“占用空间”但不会出现在 du 结果里。
