文件句柄耗尽会直接触发 oserror，因每次open()申请文件描述符且进程数量有限，未close()导致迅速占满；系统调用开销大，with语句是资源控制刚需，避免泄漏和性能损耗。
文件句柄耗尽会直接触发 OSError
每次 open() 都会向操作系统申请一个文件描述符（file descriptor），而每个进程能持有的数量是有限的（Linux 默认通常为 1024）。循环中反复 open() + 忘记 close()，几秒内就可能占满。一旦耗尽，后续任何 open()、socket()、subprocess.Popen() 都会抛出 OSError: [Errno 24] Too many open files，程序直接中断。
- 用
lsof -p $(pgrep -f your_script.py)可实时查看当前进程打开的文件数 - Python 3.7+ 中即使没显式
close()，解释器退出时也会尝试回收，但**运行中不释放**——这正是缓慢变卡的起点 - Windows 对句柄限制更严格，现象出现得更快
系统调用开销远高于内存操作
每次 open() / close() 都是一次系统调用（syscall），需从用户态切换到内核态。这个过程本身就要几百纳秒到微秒级；若循环执行 10 万次，光 syscall 切换就吃掉几十毫秒 —— 这还不算磁盘寻道、缓存失效、inode 查找等额外开销。
- 对比：读取已打开文件的
file.read(1024)是纯内存拷贝，快 1–2 个数量级 - 尤其在 SSD 或远程文件系统（如 NFS）上，重复 open/close 会让底层缓存策略失效，强制走慢路径
- 用
strace -e trace=open,close,read python your_script.py能直观看到 syscall 频次
with 语句不是“语法糖”，而是资源生命周期控制刚需
with open(...) 的本质是确保 __exit__ 在任意退出路径（包括异常、return、break）下都调用 close()。手动 try/finally 容易漏写或写错位置，而裸写 open() + close() 在中间抛异常时必然泄漏。
- 错误模式：
f = open(...); do_something(); f.close()—— 若do_something()抛异常，f.close()永远不执行 - 正确姿势必须是：
with open(...) as f: ...，哪怕只读一行也该如此 - 如果真需要复用同一个文件多次（比如循环中反复 seek + read），就在循环外
with打开，而不是在循环内反复进出
大文件场景下还叠加缓冲区重建成本
每次 open()，Python 的 I/O 层都会为该文件对象重新分配和初始化缓冲区（默认 8KB）。频繁新建/销毁缓冲区不仅增加内存分配压力，还会导致 CPU 缓存行频繁失效，尤其在多核机器上引发 cache line bouncing。
- 小文件（
- 用
io.DEFAULT_BUFFER_SIZE可查默认缓冲大小，但不要试图手动调大来“弥补”——治标不治本 - 真正要做的，是把文件访问逻辑从“按需打开”变成“按需读取”：一次打开，多次读；或一次性读入内存（仅限小文件）
open() 在后台悄悄吃掉了文件描述符配额、触发了内核锁竞争、让 CPU 缓存反复刷洗——这些都不会报错，只会让程序越来越沉。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
