答案是：lsof /path/to/file 返回空的主因是权限不足或路径不精确；需加sudo、用绝对路径，并注意软链接、inode变更等干扰因素。
Linux 没有“锁死”这个系统级概念——文件不会被程序“锁死”，只有进程持有打开的文件描述符（fd），或通过 flock()、fcntl() 等系统调用施加建议性锁（advisory lock）。所谓“查不到、删不掉、释放不了空间”，90% 是 fd 未关闭，不是锁本身在阻拦。
为什么 lsof /path/to/file 返回空，但文件明显被占用？
根本原因就两个：权限不够、路径不对。
- 普通用户运行
lsof /var/log/syslog几乎必然为空——/proc/PID/fd/对非所有者不可读，必须加sudo - 路径必须绝对且精确：
lsof ./config.yaml无效；lsof /home/app/config.yaml才行 - 软链接默认不展开，若目标是链接指向的真实文件，得加
-L参数：sudo lsof -L /etc/nginx/conf.d - 文件刚被
mv或cp --reflink，inode 已变，旧路径查不到，得按新路径重试
怎么确认是文件描述符没关，还是真有 advisory lock？
lsof 和 fuser 只能告诉你“谁打开了它”，不能直接告诉你“是否加了锁”。要区分这两类问题：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 看
lsof输出的FD列：REG+w表示正在写入（fd 活着），cwd只表示当前工作目录，未必真操作该文件 - 看
NAME列末尾是否带(deleted)：有则说明文件已rm，但 fd 未 close，磁盘空间不会释放 - 真正查锁要用
/proc/locks或lslocks：lslocks | grep $(stat -c "%d:%i" /path/to/file)，靠 inode 匹配；cat /proc/locks里每行含锁类型（FLOCK或POSIX）、PID、模式（WRITE/READ） -
lsof的LOCK列（如有）只在部分版本支持，且仅对少数锁类型生效，不可依赖
查不到锁，但想快速验证文件能否被其他进程访问？
用 flock -n 做非阻塞试探——它不改变状态，只返回是否冲突：
flock -n /path/to/file -c 'echo "unlocked"' || echo "locked"
- 成功执行
echo "unlocked"，说明当前无写锁阻挡（注意：它只测flock()类型，对fcntl()字节范围锁无效） - 失败输出
locked，不代表文件一定被“占用”，只是已有进程持有了兼容性不满足的锁 - 不要用
flock -x或fcntl写代码反复探测——频繁加锁/解锁可能干扰原进程行为 - 更稳妥的方式是先
sudo lsof /path/to/file找出 PID，再cat /proc/PID/fdinfo/数字查具体 fd 的flags和锁状态（需 Linux ≥2.6.22）
最易被忽略的点：advisory lock 本质是协作机制，内核不强制拦截。一个进程即使没调用 flock()，只要 open() 了文件，就可能被另一个进程的锁逻辑拒绝访问——而你从 lsof 或 /proc/locks 里根本看不到这种“隐形占用”。这时候得靠应用日志或 strace 跟踪实际 read()/write() 行为。
