必须显式调用 close() 或使用 with 语句，因 gc 不保证及时回收，易致文件句柄耗尽；close() 后操作会立即报 valueerror；with 可确保异常时仍关闭；zipfile、sqlite3.connection 等非文件对象同样需 close()。
什么时候必须用 close() 而不是依赖 GC 自动回收
Python 文件对象在被垃圾回收时确实会自动调用 close()，但**不能靠它保底**。GC 触发时机不确定，尤其在长生命周期进程（如 Web 服务、数据管道）里，文件句柄可能卡住几十秒甚至更久，导致 OSError: [Errno 24] Too many open files。
- 显式调用
close()是唯一能立即释放系统资源的方式 -
with语句本质就是帮你做这件事——退出块时强制调用__exit__，进而触发close() - 手动打开又忘记
close()的代码，在压力测试或长时间运行后大概率崩
close() 调用后还能读写吗？常见误判点
调用 close() 后再操作文件对象，会立刻抛出 ValueError: I/O operation on closed file。这不是警告，是硬性报错，且不会因缓存、延迟写入等机制而“偶尔成功”。
- 别在
close()后还调用read()、write()、seek()等任何 I/O 方法 -
closed属性可用来判断状态：f.closed返回True表示已关闭 - 注意：
f.close()多次调用是安全的，不会报错，但也没任何效果
with 语句没执行完就异常退出，close() 还会调用吗
会。这是 with 最关键的价值：无论正常结束还是中途 raise、return、sys.exit()，只要进了 with 块，退出时必定执行 __exit__，也就是保证 close()。
- 对比裸写
f = open(...); do_something(); f.close()：一旦do_something()抛异常，f.close()就跳过了 -
with不等于“更简洁”，而是“不漏关”——这是资源管理的底线 - 自定义类若要支持
with，必须实现__enter__和__exit__，且后者里要负责清理逻辑
哪些对象有 close() 但不是文件？容易混淆的场景
close() 不是 file 专属方法，很多资源型对象都实现了它，比如 zipfile.ZipFile、sqlite3.Connection、urllib.request.urlopen() 返回的响应对象，甚至某些网络库的 socket 封装。
立即学习“Python免费学习笔记（深入）”；
- 它们共同特点是：占用操作系统级资源（fd、socket、锁、内存映射等），需主动释放
- 同样适用
with模式，例如：with zipfile.ZipFile('a.zip') as z: - 误以为只有
open()才需要关，结果让数据库连接泄漏、Zip 文件锁死、HTTP 连接堆积，都是真实踩过的坑
close()」这一类——因为没在教程里反复强调，开发者凭直觉只盯 open()，结果在压缩包处理或轻量 DB 场景下静默泄漏。 
