psutil.Process().open_files() 不能可靠检测文件占用：仅返回本进程打开的文件，Windows需管理员权限且无法识别独占锁或已关闭但句柄未释放的情况；跨平台应聚焦操作时异常处理而非预检。
psutil.Process().open_files() 能否可靠检测文件占用？
不能直接用，open_files() 只返回该进程自己打开的文件，且 Windows 上需管理员权限才能读取其他进程的句柄信息；普通用户调用会抛 psutil.AccessDenied。更关键的是，即使有权限，它也不包含“当前正被写入”或“独占锁”的语义——比如一个进程用 open(..., 'w') 打开后立刻关闭文件对象，但文件句柄可能尚未释放（尤其在 Windows 上），open_files() 就查不到。
Windows 下真正可行的检查：用 psutil 遍历所有进程的句柄并匹配路径
Windows 文件系统在进程持有句柄时会阻止删除/重命名，因此最接近“被占用”的定义是：有其他进程打开了该文件的句柄。psutil 提供 Process().handles()（仅 Windows），但返回的是句柄 ID 和类型，不带路径。需要结合 psutil.win_service_iter() 之外的手段——实际得调用底层 API 或借助 pywin32。不过，psutil 自 5.9.0 起在 Windows 上支持 Process().open_files() 的扩展行为：若以管理员权限运行，它能解析出部分句柄对应的文件路径（依赖 NtQuerySystemInformation 和符号链接解析）。
- 必须用管理员权限启动 Python 进程，否则跳过所有非自身进程
- 不是所有句柄都能解析出路径（例如内存映射文件、设备句柄会返回
None） - 路径比较前需统一为绝对路径并规范化（
os.path.abspath()+os.path.normcase()），否则大小写或.\前缀会导致误判 - 示例逻辑：
import psutil
import os
def is_file_in_use(filepath):
abspath = os.path.abspath(filepath)
normpath = os.path.normcase(abspath)
for proc in psutil.process_iter(['pid', 'name']):
try:
for file_info in proc.open_files():
if os.path.normcase(file_info.path) == normpath:
return True, proc.info['pid'], proc.info['name']
except (psutil.AccessDenied, psutil.NoSuchProcess):
continue
return False, None, None
Linux/macOS 下没有等价句柄遍历，得换思路
Unix 系统没有“文件被占用即无法删除”的强约束（unlink 后文件内容仍存在直到所有 fd 关闭），所以严格意义的“占用检测”本身就不成立。常见替代方案是尝试以独占模式打开文件：
- 用
os.open(filepath, os.O_RDWR | os.O_EXCL)——但O_EXCL在 Linux 上对已存在文件无效，只对O_CREAT生效 - 更实用的是尝试加锁：
flock(fd, LOCK_EX | LOCK_NB)，失败说明有其他进程持有写锁（注意：仅对同一文件描述符有效，且不跨 NFS） - 或者用
lsof +D /path/to/dir外部命令解析输出（需安装 lsof，且路径需为目录才能递归查子文件） - 简单场景下，直接
os.rename(filepath, filepath)看是否报PermissionError或BlockingIOError——这模拟了“能否移动”，在多数业务逻辑中已足够近似“是否可安全覆盖”
跨平台封装建议：别执着于“是否占用”，聚焦具体操作意图
真实需求几乎都不是“单纯判断占用”，而是“能否安全写入/删除/替换”。与其花力气遍历句柄，不如按动作设计容错：
立即学习“Python免费学习笔记（深入）”；
- 写入前：用
try/except捕获PermissionError、IOError，配合退避重试 - 替换文件：先写临时文件，再
os.replace()（原子性），失败则清理临时文件并报错 - 日志类场景：用
logging.handlers.RotatingFileHandler，它内部处理了多进程写入竞争 - 若必须预检，Windows 用管理员权限 +
open_files()，其他系统默认认为“可操作”，仅在操作失败时反馈
句柄遍历本身开销大、权限要求高、结果不稳定，容易让人误以为得到了确定结论，其实只是某个瞬间的快照。真正的健壮性来自操作时的异常处理，而不是预判。
