必须加sudo且用绝对路径，否则普通用户无法读取root进程的fd；软链接需加-l参数；name列带(deleted)表示文件已删但未释放空间。
直接用 lsof /path/to/file，但 90% 的“查不到”不是命令不对，而是没加 sudo 或路径写错了。
必须加 sudo 且用绝对路径
普通用户运行 lsof /var/log/syslog 经常返回空——不是没人用，而是你没权限读取 root 进程的 /proc/PID/fd/。真实场景中，日志、配置、设备节点几乎全由 root 或服务用户（如 www-data）持有。
- 路径必须完整：
lsof ./config.yaml无效，得写lsof /home/user/app/config.yaml - 软链接默认不跟随；若目标是链接指向的真实文件，加
-L参数：sudo lsof -L /etc/nginx/conf.d -
FD列看到cwd表示该进程当前工作目录是这个路径，未必真在读写它；REG+w或u才说明正在写入或读取 -
NAME列末尾带(deleted)，说明文件已被rm但 fd 未关，磁盘空间不会释放
查不到结果？先确认这三件事
别急着换命令，90% 的失败源于基础条件不满足：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 是否用了
sudo lsof /path/to/file？这是最关键一步，别跳过 - 路径是否被
bind mount或overlayfs隐藏？lsof查的是内核实际打开的路径，不是你ls看到的表层路径 - 文件是否刚被
mv或cp --reflink操作过？inode 可能已变，旧路径查不到，得按新路径重试
替代方案：没装 lsof 时手动翻 /proc/PID/fd
某些最小化系统或容器里没装 lsof，但 /proc 是内核原生接口，永远可用：
- 先用
ps aux | grep keyword或pgrep -f nginx找出疑似 PID - 再执行
ls -l /proc/1234/fd/ | grep your_filename查该进程打开了哪些文件 - 用
readlink /proc/1234/fd/7看 fd 7 指向的真实路径（含(deleted)提示） - 注意：
/proc/PID/fd/方法需要先知道 PID，而lsof的核心价值是“给路径就能反查 PID”
别用 fuser 查普通文件
fuser /path/to/file 对普通文件识别率低，常漏掉 vim、tail -f、rsyslogd 这类行为。它更适合查挂载点（fuser -m /mnt/data）或端口（fuser 80/tcp）。
真正容易被忽略的是：即使你确认了路径和权限，如果文件在某个独立挂载的子目录下（比如 /var/log/journal 是单独挂载的），lsof +d /var/log 也不会扫描进去——得单独对那个挂载点再跑一次。
