确认inode是否耗尽应直接运行df -i看iuse%列是否达100%，因其是内核级、全挂载点的权威指标；df -h只反映磁盘块空间，ls统计不准确且无法跨挂载点，均不可替代。
直接运行 df -i，看 IUse% 列是否达到 100% —— 是，就确认耗尽；不是，问题不在 inode。
为什么只用 df -i，不用 df -h 或 ls
磁盘空间（block）和 inode 是两套独立资源。df -h 只显示容量，完全不反映 inode 状态；ls -a | wc -l 在文件数超几万时会崩溃或卡死，且无法跨挂载点准确统计。只有 df -i 是内核级、实时、全挂载点的权威指标。
常见误操作包括：
- 只跑
df -i /，却忽略/var、/home这类可能独立挂载的分区 - 在容器或精简系统中看到
df -i输出没 IUse% 列，误以为没问题——其实是工具阉割了，应改用stat -f /查Inodes:和Inodes free:字段手动计算 - 把
/proc或/sys下的“文件”数量当真——它们是虚拟文件系统，不消耗真实 inode
看到 IUse% = 100% 后，下一步必须查哪个挂载点
重点盯住实际存业务数据的挂载点，比如 /、/var、/home、/data。tmpfs、devtmpfs 这类内存文件系统的高 IUse% 属正常，不用管。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
快速定位方法：
- 执行
df -i，扫一遍所有行，挑出 IUse% ≥ 95% 的挂载点 - 对高危挂载点（如
/var），用du --inodes -s /var/* 2>/dev/null | sort -nr | head -5找子目录级大户 - 典型重灾区路径：
/var/log/journal、/var/spool/postfix/maildrop、/tmp/systemd-private-*、/var/lib/docker/overlay2
清理前先确认文件是否真能删：小心已删未释的 inode
执行 rm 后 df -i 不变？说明文件被进程持有着 fd，只是 unlink 了。这类文件在 lsof +L1 输出里 NAME 列带 (deleted)。
关键点：
- 别用
lsof | grep deleted—— 漏匹配、慢、不准 -
lsof +L1是内建过滤，只列 link count 为 0 的条目 - 释放依赖进程行为：Java 应用需 GC 或重启；nginx 日志 reopen 不一定立即释放；有些服务得 reload 配置才能 close fd
真正棘手的从来不是“怎么删”，而是“删了还占着”——查 lsof +L1 这步漏掉，清理就白做。
