必须加sudo且用绝对路径才能准确查到占用进程；普通用户无权读取其他用户/proc/pid/fd目录，软链接需加-l，cwd不表示读写而reg+w/u才表示，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% 的失败源于基础条件不满足：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 是否用了
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 也不会扫描进去——得单独对那个挂载点再跑一次。
