portalocker加锁失败但没报错，是因为默认lock()是阻塞式，文件被占时进程会挂起等待而非报错；需加timeout=0触发lockexception。
portalocker加锁失败但没报错，怎么回事？
默认情况下 portalocker.lock() 是阻塞式加锁，如果文件已被其他进程锁住，当前进程会一直卡住——看起来像“没反应”，实际是挂起等待。这不是 bug，而是设计行为。
常见误判场景：在 IDE 或 Jupyter 里运行测试脚本，忘记关掉前一个运行实例，新进程就静默卡死。
- 加锁前务必确认目标文件未被其他 Python 进程（或任意调用
flock/LockFileEx的程序）占用 - 强制非阻塞：传入
timeout=0，锁不可用时立刻抛出portalocker.LockException - Windows 下若用
portalocker.LockFlags.EXCLUSIVE锁住文件，另一进程尝试以写方式打开该文件会直接失败（PermissionError），不是锁等待
Linux 和 Windows 的锁行为差异在哪？
portalocker 底层在 Linux 调用 flock()，Windows 调用 LockFileEx()，两者语义不完全等价：
- Linux
flock是建议性锁（advisory），仅对也调用flock的进程生效；绕过它直接读写文件完全不受限 - Windows
LockFileEx是强制性锁（mandatory），只要锁区间被占用，任何进程对该区域的读/写系统调用都会失败（但注意：Python 的open()默认不检查锁，需手动触发 I/O 才暴露错误） - 跨平台一致写法：始终用
portalocker.lock(fp, portalocker.LOCK_EX)，不要混用os.open()+fcntl.flock()等原生接口
为什么用 with portalocker.Lock() 后文件还是被并发修改了？
典型错误是锁对象生命周期管理不当。下面这段代码看似安全，实则无效：
with portalocker.Lock('data.txt', 'w') as f:
f.write('new data')
# 文件句柄 f 在 with 块结束时关闭，锁自动释放
# 但写入内容可能还没刷到磁盘，其他进程已拿到锁并读到旧内容
真正需要保护的是「读-改-写」原子操作，而不是单次 write() 调用。
- 写入后必须显式
f.flush()，必要时加os.fsync(f.fileno())确保落盘 - 避免在锁内做耗时操作（如网络请求、大文件复制），否则严重拖慢其他进程
- 若需多步操作保持一致性，把所有逻辑塞进同一个
with portalocker.Lock(...)块里，别拆开
如何安全地在多个 Python 脚本间共享锁？
关键不是“怎么加锁”，而是“锁什么”。不同脚本必须操作同一文件路径，且路径不能是相对路径或临时路径（比如 ./config.lock 在不同工作目录下指向不同文件）。
- 使用绝对路径：
os.path.abspath('config.lock')或硬编码完整路径（如/var/run/myapp.lock） - Linux 下注意文件系统是否支持
flock（NFS 默认不支持，需挂载时加nolock参数） - Windows 下确保所有脚本都以相同权限运行（管理员 vs 普通用户之间无法共享锁）
- 锁文件本身无需内容，空文件即可；但不要用日志文件或数据文件兼作锁文件——容易引发竞态和误删
跨平台锁的脆弱点不在库本身，而在于路径解析、权限模型和文件系统特性。哪怕 portalocker 写得再严谨，一个相对路径就能让整个锁机制失效。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
