du -h --max-depth=n用于限制目录深度统计：--max-depth=0仅显示当前目录总大小，--max-depth=1显示当前目录及一级子目录大小，--max-depth=2则扩展至二级子目录但不进入三级。
du -h --max-depth=N 查看指定层级的目录大小
直接用 du -h --max-depth=1 只能看当前目录下一级子目录的大小，但“深层目录”不是指“很深”，而是你想聚焦某一层（比如只看二级子目录、不看三级以下），这时必须明确指定 --max-depth 数值。
常见误区是以为加个 -R 或省略参数就能“深入”，其实默认会递归到底，输出成百上千行，根本没法定位目标层级。
-
--max-depth=2：显示当前目录 + 所有一级子目录 + 所有二级子目录（但不展开三级） -
--max-depth=0：只显示当前目录自身总大小（等价于du -sh） -
--max-depth=1：最常用，只列当前目录下的直接子项，适合快速扫描“谁占空间最多”
示例：想看 /var/log 下每个服务日志目录（如 nginx/、docker/）本身的大小，但不想被它们内部的 archive/ 或日期子目录刷屏，就运行：
du -h --max-depth=1 /var/log
du -sh * 和 du -sh */ 区别在哪
表面看都“列出当前目录内容”，但行为完全不同：du -sh * 会展开所有匹配项（包括文件），而 du -sh */ 只匹配目录（末尾带 / 的路径），天然过滤掉文件，避免误把大日志文件当目录统计。
更关键的是，* 在 shell 层就被展开，如果目录名含空格或特殊字符（如 my app/），du -sh * 会报错或漏统计；*/ 更安全，且语义清晰——你要的就是目录。
- 要纯看子目录大小（不含文件）→ 用
du -sh */ - 要同时看子目录和同级大文件 → 用
du -sh * - 担心路径含空格 → 改用
find . -maxdepth 1 -type d -not -path . -exec du -sh {} \;
为什么 du 输出和 df 显示的空间不一致
这不是命令写错了，而是底层机制差异：du 统计的是“文件实际占用的块”，df 统计的是“文件系统级已分配块”。当一个大文件被 rm 删除，但仍有进程在读写它（比如 tail -f 正盯着日志），du 不再计入，df 却还占着空间——直到该进程退出。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
典型场景：清理 /var/log 后 df 没变化，但 du 已变小。此时得用 lsof +L1 或 sudo fuser -v /var/log 找出持有已删文件的进程，再 kill 它。
- 别只信
df -h判断“磁盘满不满”，先du -sh /* 2>/dev/null | sort -hr定位大目录 - 发现
du和df差异 > 几百 MB → 基本可判定有“deleted but still open”的文件 -
du结果偏小 ≠ 磁盘真空了，可能只是内核还没回收块
排序找最大目录时 sort -h 的兼容性坑
du -sh */ | sort -hr 看起来很顺，但老版本 sort（如 CentOS 6 默认的）不支持 -h，会报错或按字母序排（9K 排在 10M 前面）。这不是你命令写错，是系统工具链旧。
安全做法是用 du -k */ | sort -nr（以 KB 为单位数值排序），再人工换算，或者升级 coreutils：
du -k */ | sort -nr | head -10 | awk '{printf "%s\t%s\n", $1/1024/1024"GB", $2}'
注意：sort -h 要求 GNU sort ≥ 7.5（2009 年后发行版基本都有），但嵌入式或定制系统可能仍卡在旧版本。
真正容易被忽略的点：即使用了 sort -h，如果 du 输出里混入了权限错误提示（如 du: cannot access 'xxx': Permission denied），这些文本行会被 sort 当作字符串排到最前，导致结果错乱。加 2>/dev/null 是实操底线。
