Python的GC不管理文件句柄，仅回收内存对象；文件描述符等系统资源需靠with或显式close()释放，否则会导致句柄耗尽、数据丢失或文件被占用。
Python的垃圾回收不管理文件句柄
Python确实有垃圾回收（GC），但它只负责内存对象的引用计数和循环引用清理，File对象底层持有的操作系统资源——比如file descriptor（文件描述符）——不在GC管辖范围内。GC能回收file对象本身，但不会调用close()去释放对应的系统级句柄。一旦大量文件打开后未关闭，file descriptor持续累积，很快就会触发OSError: Too many open files。
- Linux/macOS 默认每个进程最多打开 1024 个文件描述符；Windows 也有限制（通常 512–2048）
- 即使程序只读打开文件，也会占用一个描述符
- GC 触发时机不确定：可能等几秒、几分钟，甚至等到进程退出才回收——这期间资源已泄漏
- 在长期运行服务（如 Flask/FastAPI 后端）中，漏关文件会随请求累积，最终崩溃
写入数据可能滞留在缓冲区
Python 默认启用缓冲（buffering= -1），write() 调用只是把数据塞进内存缓冲区，并不立即落盘。只有调用 close() 或显式 flush() 才强制刷出。如果程序异常退出（比如 KeyboardInterrupt 或未捕获的 Exception），而文件又没被 close()，那最后几 KB 数据就永远消失了。
立即学习“Python免费学习笔记（深入）”；
-
with open(...)能保证close()执行，哪怕中间抛异常 -
open(..., buffering=0)可禁用缓冲（仅限二进制模式），但牺牲性能，且仍需关闭 -
print(..., file=f)同样受缓冲影响，不能依赖“写完就安全”
手动 close() 容易踩的坑
直接调用 f.close() 看似简单，但在真实代码里极易出错：
- 忘记放在
finally块里 → 异常时跳过关闭 - 对已关闭的文件再调用
close()→ 抛ValueError: I/O operation on closed file（虽不崩溃，但暴露逻辑缺陷） - 多处 return 或 break 早于
close()→ 隐蔽漏关 - 误以为只读文件不用关 → 错，只读同样占用
file descriptor
with 语句不是银弹，缩进和作用域很关键
with 是目前最可靠的方案，但它的自动关闭只发生在离开代码块时。常见疏忽包括：
- 把文件操作写在
with块外 →f已关闭，后续读写直接报错ValueError - 提前赋值给外部变量（如
data = f.read()再return data）没问题；但若赋值的是f本身（global_f = f），离开with后它就失效了 - 嵌套
with时搞混层级，尤其处理多个文件时容易漏掉某一个 - 用
pathlib.Path.open()时仍需with，不能因为路径对象“更现代”就省略上下文管理
真正容易被忽略的是：文件关闭不是“做完事就结束”的动作，而是资源生命周期的终点。只要文件对象还活着（哪怕你只调用了一次 readline()），它就在占用系统资源——这个事实和语言有没有 GC 毫无关系。
