open()失败时应在外围处理并明确恢复状态，优先用with确保自动关闭；写入中断需用临时文件+原子替换防损坏；多进程需os.open(..., O_EXCL|O_CREAT)独占创建；FileHandler无自愈能力，需自定义降级策略。
open() 失败时如何安全回退
文件打开失败（比如权限不足、路径不存在）不是小问题，它往往意味着后续所有写入逻辑都该立即终止，而不是硬着头皮往下走。关键不是“捕获异常”，而是“明确知道该恢复到什么状态”。
- 别在
open()外层包一层空的try/except就完事——没释放的资源、没清理的临时文件、没重置的状态，都会让恢复变成假象 - 优先用
with open(...)：它保证即使open()成功但后续语句抛异常，文件对象也会被自动关闭；但如果open()本身失败，with块根本进不去，得在外围处理 - 如果必须手动管理句柄（比如需要复用或延迟关闭），记得在
except分支里显式检查变量是否已赋值，避免UnboundLocalError - 常见错误现象：
FileNotFoundError或PermissionError抛出后，程序继续执行并试图对未定义的f调用.write()，结果报NameError: name 'f' is not defined
写入中断后如何判断文件是否损坏
磁盘满、进程被杀、断电……这些不会抛 Python 异常，但会导致文件内容截断或乱码。靠 os.path.getsize() 对比预期长度并不靠谱——写入缓冲区可能还没刷盘，或者部分数据已落盘但元数据没更新。
- 写入前先生成临时文件（如
data.json.tmp），全部写完再os.replace()原子替换原文件——这是最实用的“损坏防护”手段 - 不要依赖
f.flush()或os.fsync()来确保落盘：它们能降低风险，但不能 100% 防止断电丢数据，且会拖慢性能 - 如果业务允许，写入后加简单校验：比如 JSON 文件用
json.loads()尝试解析，CSV 用csv.Sniffer().sniff()检查头部——失败就删掉临时文件，不覆盖原文件 - 注意
os.replace()在 Windows 上对同目录移动是原子的，在 Linux 上跨文件系统会退化为复制+删除，此时不具原子性
多进程同时操作同一文件的恢复陷阱
多个 Python 进程（或线程）直接读写同一个文件，不加协调机制，恢复设计就毫无意义——你修复了 A 进程的中断，B 进程可能正在覆盖它的修复结果。
-
os.open(..., os.O_EXCL | os.O_CREAT)是唯一可靠的创建+独占手段，配合os.close()和异常清理，比flock()更跨平台 - 避免用
time.sleep()等待文件解锁——竞态条件依然存在，且无法应对进程僵死 - 日志类场景常用“按时间戳命名+定期归档”，本质是绕开并发冲突，而不是解决它；恢复逻辑只需关注单个文件的完整性
- 常见错误：用
os.path.exists()判断文件是否存在，然后open('file', 'w')——两个进程同时通过判断，接着同时打开写入，结果互相覆盖
logging.FileHandler 的异常恢复能力很弱
标准库 logging.FileHandler 设计目标是“尽力而为”，不是“故障自愈”。它不会重试、不处理磁盘满、不备份损坏日志，出问题就静默丢弃日志。
立即学习“Python免费学习笔记（深入）”；
- 如果日志丢失不可接受，别直接用
FileHandler，改用RotatingFileHandler并设置backupCount > 0，至少保留历史副本 - 想实现写入失败后转存到内存或本地 SQLite，得自己封装
Handler子类，在emit()里捕获OSError并降级处理 - 注意
delay=True参数：它推迟文件打开时机，避免程序启动时因路径不存在直接崩溃，但首次写入失败仍需单独处理 - 一个容易被忽略的点：
FileHandler在 fork 后的子进程中会继承父进程的文件描述符，若父进程已关闭文件，子进程可能遇到Bad file descriptor
