资源泄漏主因是异常跳过清理逻辑，应优先用with语句（含async with）确保__exit__或__aexit__在任何退出路径下执行，自定义类需正确实现且不误吞异常。
资源泄漏常发生在异常跳过 cleanup 逻辑时
Python 中的资源泄漏（如文件未关闭、数据库连接未释放）多数不是因为忘了写 close()，而是因为异常在资源使用中途抛出，导致后续 cleanup 代码根本没机会执行。比如用 open() 打开文件后，在读取过程中触发 UnicodeDecodeError，若没做保护，file.close() 就会被跳过。
常见错误写法：
f = open('data.txt')
data = f.read() # 这里可能抛异常
f.close() # 永远不会执行
- 任何手动调用
close()、disconnect()、release()的地方，都面临同样风险 - 即使加了
try/except，如果只捕获特定异常类型（如只捕ValueError），其他异常仍会绕过清理 - 多层嵌套资源（如文件 + 网络连接）会让手动管理逻辑迅速失控
用 with 语句替代裸 try/finally
with 不是语法糖，它背后调用的是对象的 __enter__ 和 __exit__ 方法，而 __exit__ 在**任何退出方式下都会被调用**——包括正常 return、break、continue，以及所有未被捕获或已捕获的异常。
正确做法：
立即学习“Python免费学习笔记（深入）”；
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
with open('data.txt') as f:
data = f.read() # 即使这里抛异常，f.__exit__() 也会确保 close()
- 标准库中支持
with的类型：文件对象、threading.Lock、contextlib.closing包裹的任意带close()的对象 - 第三方库如
psycopg2（PostgreSQL）、requests.Session（部分版本）、sqlite3.Connection都实现了上下文协议 - 自定义类只需实现
__enter__和__exit__，就能用with管理资源生命周期
自定义资源类必须正确处理 __exit__ 的返回值
__exit__(self, exc_type, exc_value, traceback) 的返回值决定异常是否继续向上抛出。返回 True 表示“已处理”，异常消失；返回 None 或 False 表示“未处理”，异常照常传播。大多数资源类不该吞掉异常。
典型错误：
def __exit__(self, *args):
self.close()
return True # ❌ 吞掉所有异常，调用者完全不知道出错了
- 除非你明确要压制异常（如日志记录后忽略），否则不要返回
True - 资源释放本身也可能失败（如网络连接 close 时超时），应在
__exit__内部用try/except包住close()，避免干扰原异常传播 - 若需在异常发生时执行额外逻辑（如回滚事务），应在
__exit__中检查exc_type is not None，而不是靠返回值
异步代码中 async with 不能被普通 try/except 替代
在 async def 函数里，await 可能挂起并恢复多次，普通 try/finally 无法保证异步 cleanup 的原子性。比如 await db.acquire() 成功后，在 await db.query() 前被取消（CancelledError），手动 finally 块里的 await db.release() 可能因事件循环状态异常而失败。
- 必须用
async with（对应__aenter__/__aexit__）来管理异步资源 - 常见支持类型：
aiomysql.Pool、httpx.AsyncClient、aiofiles.open() - 不要在
async with块内混用同步 I/O（如time.sleep()），这会阻塞整个协程调度
实际项目中最容易被忽略的，是那些「看起来不重要」的资源：临时目录、内存映射文件、子进程句柄、甚至某些 C 扩展模块分配的内部缓冲区——它们不走 Python 的 GC 路径，一旦漏关，就只能靠进程退出强制回收。
