最准确方法是直接查看 /proc/[pid]/fd 目录，该目录由内核实时维护，每个数字条目对应一个已分配的文件描述符，ls /proc/[pid]/fd | grep -E '^[0-9]+$' | wc -l 可得精确数量；lsof -p [pid] 需加 sudo 并排除表头才可靠，但主要用于查看类型与路径而非计数。
怎么查某个进程实际用了哪些文件描述符
直接看 /proc/[pid]/fd 是最准的——它不是估算，是内核实时维护的符号链接目录，每个数字条目就是一个已分配的 fd。只要进程还活着，这里就反映真实状态。
- 先用
pgrep nginx或ps aux | grep redis拿到 PID，别靠肉眼数ps输出里的行号 - 执行
ls -l /proc/1234/fd，输出里每行一个 fd（如0 -> /dev/pts/0），总行数 = 当前打开数 - 注意：
ls /proc/1234/fd | wc -w更快，但会把.和..算进去；稳妥写法是ls /proc/1234/fd | grep -E '^[0-9]+$' | wc -l - 如果看到大量
socket:[1234567]或anon_inode:[eventpoll]，说明进程在用网络连接或 epoll，不是普通文件
为什么 lsof -p [pid] | wc -l 常不准
lsof 默认需要 root 权限才能读全所有 fd；非 root 用户执行时，遇到权限不足的条目会跳过或报错，导致统计偏少，且表头行（COMMAND PID ...）也会被计入，必须手动减 1。
- 真正可靠的做法是：
sudo lsof -p 1234 2>/dev/null | tail -n +2 | wc -l（跳过表头，忽略权限错误） - 但更轻量、无依赖、不需 sudo 的方式仍是
ls /proc/1234/fd | grep -E '^[0-9]+$' | wc -l -
lsof的价值不在计数，而在看类型和路径：比如区分REG（普通文件）、IPv4（TCP 连接）、DIR（目录），这对排查泄漏特别有用
怎么确认 fd 是不是真“开着”而不是残留
内核不会立即回收已 close() 的 fd，尤其当有子进程继承或存在引用计数延迟时，/proc/[pid]/fd 里可能短暂残留无效链接。判断依据不是“有没有”，而是“能不能 readlink”。
- 运行
readlink /proc/1234/fd/37，如果返回No such file or directory，说明这个 fd 已关闭，只是目录项还没刷新 - 若返回路径（如
/var/log/nginx/access.log）或socket:[1234567]，则该 fd 确实处于活跃打开状态 -
cat /proc/1234/status | grep -E 'FDSize|FDs'只给近似值：其中FDs是内核当前认为该进程正在使用的数量，比ls /proc/1234/fd少 1–2 个通常属正常
系统级 fd 分配到底卡在哪一层
单看进程 fd 数够不够没用，得确认每一层限制都松开了：从内核总量 → 单进程硬上限 → systemd 服务配置 → 进程实际生效值，漏一层就白调。
- 查系统总量：
cat /proc/sys/fs/file-max（不是sysctl fs.file-max，后者可能缓存） - 查单进程硬上限：
cat /proc/sys/fs/nr_open，如果它比file-max小，新进程连申请都失败 - 查 systemd 服务是否生效：
cat /proc/$(pgrep -f 'redis-server')/limits | grep "Max open files"，必须看到 Soft 和 Hard 都是你设的值 - 容器场景下，
docker run --ulimit nofile=65536:65536必须显式加，宿主机ulimit对容器内进程完全无效
真正起作用的永远是 /proc/[pid]/limits 里的数字，其他地方写的全是纸面承诺。
