必须用sudo lsof才能查全系统进程，因普通用户默认仅能读取自身/proc/PID/fd/目录，无权限访问其他进程文件描述符及内核内存。
lsof 命令查不到进程打开的文件？先确认权限和 root 权限
普通用户运行 lsof 时，默认只能看到自己进程打开的文件；系统级资源（如其他用户的进程、网络监听端口、内核模块加载的设备）必须用 sudo lsof 才能完整列出。常见错误是直接执行 lsof -i :8080 却返回空，其实是因为没权限读取目标进程的 fd 目录。
- 非 root 用户执行
lsof -p <code>PID可能报错：can't identify protocol或直接无输出——不是命令错，是 /proc/PID/fd/ 不可读 -
sudo lsof -iTCP -sTCP:LISTEN是查所有监听 TCP 端口最稳妥的方式，不依赖进程属主 - 某些容器环境（如 rootless Podman）中即使加了
sudo，lsof仍无法穿透 user namespace，此时需进容器内执行
查端口被谁占用：用 -i 和 -n 避免 DNS 解析拖慢响应
lsof -i :3000 看起来简单，但默认会尝试反向解析 IP 为域名，遇到网络不通或 DNS 慢时卡住几秒。生产排查要快，必须禁用解析。
- 加
-n参数：lsof -ni :3000—— 强制显示 IP 地址而非主机名，响应立刻返回 - 限定协议更精准：
lsof -niTCP :3000排除 UDP 干扰；lsof -niUDP :53单独查 DNS 端口 - 输出字段里
COMMAND列可能被截断，加+L1显示完整命令路径：lsof -niTCP :3000 +L1
定位删除但仍被占用的文件：用 +L1 和 -O 查 deleted 状态
文件被 rm 删除后，若还有进程在读写它，磁盘空间不会释放。这种“幽灵文件”在 lsof 输出中表现为 DEL 或 (deleted) 标记，但路径已不可访问。
- 查所有已删但仍在用的文件：
lsof +L1——+L1表示 link count 为 0，即硬链接数归零（典型删除态） - 配合
-O显示文件偏移量：lsof -O +L1，能看出进程当前读写位置，辅助判断是否还在持续写入 - 注意：
+L1在较老内核（如 CentOS 6）上可能不支持，可用lsof | grep 'deleted'替代，但结果不稳定
过滤大量输出：用 -p、-u、-d 组合缩小范围，别靠 grep 硬筛
全量 lsof 可能输出上万行，用 grep 过滤容易漏匹配（比如 COMMAND 名含空格、路径含特殊字符），应优先用内置筛选参数。
-
-p <code>PID：只看指定进程，比lsof | grep <code>PID准确且快 -
-u <code>username：限制用户，lsof -u www-data -i查 Web 服务网络连接 -
-d <code>cwd,txt,mem：只查当前工作目录、可执行文件、内存映射段，避免混入大量 socket 或 pipe - 组合使用安全：
lsof -u nginx -d txt能快速定位 nginx 主程序路径，比ps aux | grep nginx更可靠
(deleted) 却不知道哪个日志轮转脚本忘了 kill -USR1，或者 lsof -i 显示一堆 ESTABLISHED 却分不清是客户端还是服务端——这时候得结合 ss -tulnp 交叉验证。工具只是线索，上下文才决定下一步该杀进程还是改配置。 
