最准、最轻量的方式是直接查看/proc/[pid]/fd目录，每个数字子项对应一个真实分配的文件描述符，符号链接目标即打开资源路径，实时映射且不依赖外部工具或权限。
直接看 /proc/[pid]/fd 目录是最准、最轻量的方式——它不依赖外部工具，也不受权限限制（只要能读该进程的 proc 条目），且每个数字子项就对应一个真实分配的 fd。
怎么看某个进程当前用了哪些文件描述符
Linux 内核为每个进程在 /proc/[pid]/fd 下维护一组符号链接，编号即 fd 号，目标即打开的资源路径。这不是快照或统计值，而是实时映射。
- 先拿到 PID：比如
pgrep nginx或pidof mysqld - 执行
ls -l /proc/1234/fd（把 1234 换成实际 PID）；输出里每行一个 fd，如3 -> socket:[123456]或7 -> /var/log/app.log - 想只看纯数字 fd（排除
cwd、root等伪条目）：用ls /proc/1234/fd | grep -E '^[0-9]+$' | wc -w - 注意：
0、1、2几乎总存在（stdin/stdout/stderr），别误判为泄漏
为什么 lsof -p [pid] | wc -l 常不准
lsof 输出包含表头、空行、甚至因权限不足跳过的条目，且默认会列出所有类型（包括未真正“打开”的 eventpoll、inotify 实例），导致计数虚高或漏报。
- 常见现象：
lsof -p 1234 | wc -l返回 87，但ls /proc/1234/fd | wc -w是 82 —— 多出的 5 行通常是 lsof 自己的元信息或被截断的 socket 描述 - 更可靠的做法是加
-F f输出精简 fd 列表：lsof -p 1234 -F f 2>/dev/null | grep '^f' | wc -l - 但如果你没 root 权限，
lsof很可能连自己用户的其他进程都列不全；而/proc/[pid]/fd只要进程属你、且没被 ptrace 保护，就能读
/proc/[pid]/status 里的 FDs 字段靠不靠谱
cat /proc/1234/status | grep -E 'FDs|FDSize' 显示的是内核缓存的近似值，不是实时精确计数，尤其在高并发短连接场景下容易滞后。
-
FDs: 123表示“上次更新时已用数量”，但可能刚 close 了 5 个，这里还没刷新 -
FDSize: 1024是该进程当前 fd 表分配的槽位总数，不等于 ulimit 限制（比如 ulimit -n 65536，但 FDSize 可能还是 1024 —— 内核按需扩容） - 它适合快速巡检，但排查“fd 突然涨到 65535 报错”时，必须回退到
/proc/[pid]/fd目录逐个确认
真正关键的不是数字本身，而是每个 fd 链接指向什么：如果大量 socket:[...] 或 anon_inode:[eventpoll] 却没有对应业务连接，大概率是应用没正确 close 或连接池配置过激；如果看到一堆 /tmp/xxx.tmp 且 PID 不变，就得查代码里文件是否漏 fclose。
