with语句确保__exit__执行并调用close()，但close()本身可能抛出异常（如磁盘满、网络断连），且该异常会覆盖原异常；需通过手动close()捕获或finally块处理。
用 with 语句打开文件，基本不需要手动处理“关闭异常”——因为 with 本身会确保 close() 被调用，哪怕发生异常。 真正要关注的，是那些 close() 过程中可能抛出的、被忽略的异常（比如磁盘满、网络文件系统断连），以及它们对程序逻辑的影响。
为什么 with 不能完全屏蔽 close() 异常
with 确保 __exit__ 被执行，而内置文件对象的 __exit__ 会调用 close()。但 close() 本身可能失败（尤其在写入缓冲未刷盘时），此时异常会被抛出并覆盖前面的异常（如果有的话）。
- 常见错误现象：
OSError: [Errno 28] No space left on device在with块结束时才爆出，掩盖了原本的ValueError - 使用场景：写入大文件、NFS/SMB 挂载卷、容器中临时存储卷
- 关键点：
with不捕获close()异常，只保证它被执行
如何安全地捕获并处理 close() 失败
标准做法是显式调用 close() 并捕获异常，但这会失去 with 的自动保障。更稳妥的方式是在 with 块内完成所有读写，再单独处理关闭逻辑：
try:
with open("data.txt", "w") as f:
f.write("hello")
# 其他写入操作
except OSError as e:
print(f"写入失败: {e}")
raise
<h1>此时文件已离开 with 块，但 close() 已执行 —— 无法再捕获其异常</h1><p></p>
若必须检查 close() 结果（如日志归档后需确认落盘），改用手动管理 + finally：
f = None
try:
f = open("archive.log", "wb")
f.write(b"...")
except Exception:
raise
finally:
if f is not None:
try:
f.close()
except OSError as e:
# 记录 close 失败，但不中断主流程
logger.warning(f"close failed: {e}")
close() 异常对不同文件模式的影响
不是所有模式都一样危险。重点看缓冲行为和系统调用时机：
-
"w"/"a"：写入内容先缓存在内存，close()才触发fsync()或系统写入，失败概率高 -
"r"：close()几乎不会失败（除非文件描述符被外部强制回收） -
"w+"/"a+"：同写入模式，且可能涉及seek()后的元数据更新，风险叠加 - 性能影响：显式
flush()可提前暴露问题，但会降低吞吐；频繁fsync()更慢
真正容易被忽略的是：Python 3.7+ 中，io.TextIOWrapper 的 close() 若失败，会静默丢弃异常（仅发 warning），而二进制模式或底层 os.close() 仍会抛出——这种不一致性会让调试变难。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
