普通用户执行lsof看不到其他进程，因需读取/proc/PID/fd/和内核内存，默认仅限自身进程；必须用sudo才能查看全系统进程，否则输出可能为空或不完整。
lsof 不是“安装后就能直接用”的命令——它需要权限、参数筛选和对输出字段的基本识别能力，否则 lsof 会卡住、报错或返回一堆无用信息。
为什么普通用户执行 lsof 看不到其他进程？
因为 lsof 要读取 /proc/PID/fd/ 和内核内存，普通用户默认只能看到自己启动的进程。不加 sudo 时，lsof 输出可能为空或只显示几个 shell 进程。
- 必须用
sudo lsof才能查全系统（尤其是服务类进程如nginx、mysqld） - 某些容器环境或加固系统（如 grsecurity）即使 root 也可能被限制，此时可退而求其次用
/proc/PID/fd/手动验证 -
lsof -v可确认当前版本是否支持你的内核；老版本（如 4.87 以前）在较新 kernel 上可能 crash
lsof -p PID 查指定进程打开的文件，但没结果？
常见原因不是命令写错，而是权限或进程状态问题：
- 先确认 PID 确实存在：
kill -0 PID或ps -p PID，避免查已退出的僵尸 PID - 必须加
sudo：sudo lsof -p 1234，否则连cwd和txt都看不到 - FD 列中
cwd是当前工作目录，txt是二进制文件本身，DEL或 NAME 后带(deleted)表示文件已被rm但进程仍在写入——这是磁盘空间不释放的典型信号 - 如果只想看真实磁盘文件（排除 socket、pipe、inotify），加过滤：
sudo lsof -p 1234 -a -d ^cwd,^txt,^mem,^rtd,^mmap
lsof +D /path 扫描目录时卡死或超时？
+D 是递归扫描整个目录树，遇到大日志目录（如 /var/log/journal）或 NFS 挂载点极易卡住：
- 优先用小写
+d（只扫一级）：sudo lsof +d /var/log - 路径含空格或特殊字符时，必须用引号：
sudo lsof "/mnt/my data/app.log"，否则 shell 拆分后lsof收到的是无效参数 - 若目标只是卸载失败的挂载点，先
sudo lsof +d /mount/point，再kill -TERM PID终止持有句柄的进程，比暴力umount -f更安全 -
+D在某些内核上会触发大量stat()调用，导致 I/O 阻塞；生产环境慎用
lsof -i :8080 显示多个进程，怎么确认哪个真在监听？
-i 匹配所有 TCP/UDP 关联该端口的连接（包括 ESTABLISHED、LISTEN、CLOSE_WAIT），但真正“占用端口”的只有 LISTEN 状态：
- 加状态过滤：
sudo lsof -iTCP -sTCP:LISTEN -P -n :8080（-P禁用端口名解析，-n禁用 DNS 解析，提速且避免卡在反向查询） - NAME 列末尾的
(LISTEN)才表示该进程正在监听；(ESTABLISHED)是已建立的客户端连接，不冲突 - 如果输出里有
java和node同时出现，注意看 USER 字段：可能是不同用户下的进程，sudo下才可见全貌 - 某些代理或容器网络（如 Docker 的 bridge 模式）会让
lsof显示宿主机上看似无关的进程，此时需结合docker ps或podman ps交叉验证
lsof 不是“运行即得结果”的工具，它更像一个需要配合 ps、kill、/proc 目录手动验证的诊断链条。 
