必须用finally的场景是资源获取与释放跨多分支或含return/break/continue时，因其能兜底执行清理；with依赖上下文协议且仅限语句块内生效，无法覆盖外部创建、条件化清理等复杂情况；二者可协同使用，with管标准资源，finally做兜底或补充操作。
Python里资源没及时释放，不是报错就是内存泄漏，finally 和上下文管理器（with）不是二选一，而是分场景用、有时还得一起用。
什么时候必须写 finally？
当资源获取和释放逻辑跨多个分支、或中间有 return/break/continue 时，try...except 本身不保证执行清理代码，只有 finally 能兜底。
- 函数中途
return了，但文件句柄/数据库连接还没关 - 循环里打开资源，但某次迭代出错后直接
break - 需要在异常和非异常路径下都做同一清理动作（比如重置状态变量）
def process_file(filename):
f = None
try:
f = open(filename, 'r')
data = f.read()
if 'ERROR' in data:
return 'early exit'
return data
finally:
if f is not None and not f.closed:
f.close() # 确保关闭，哪怕上面 return 了
with 语句为什么不能覆盖所有场景？
with 依赖对象实现 __enter__ 和 __exit__，但它只在语句块结束时触发清理——如果资源是在 with 块外打开的，或者清理逻辑要和业务逻辑强耦合（比如根据处理结果决定是否提交事务），with 就无能为力。
- 数据库连接在函数开头创建，但 commit/rollback 决策在中间某处才确定
- 多个资源需按特定顺序释放，且释放条件互相关联
- 自定义类没实现上下文协议，又不能改源码
这时得靠 finally 手动控制生命周期。
立即学习“Python免费学习笔记（深入）”；
finally 和 with 能不能一起用？
能，而且常见。典型模式是：用 with 管理“标准资源”（如文件、锁），再用 finally 做兜底清理或补充操作。
-
with处理可预测的资源（如open()），finally处理不可预测的副作用（如清空临时目录、重置全局标志） - 避免在
with块里做耗时或可能失败的清理，把它们移到finally中统一处理 - 注意：不要在
finally里重复关闭已被with关闭的资源，否则可能抛ValueError: I/O operation on closed file
def safe_download(url):
tmpfile = '/tmp/download.tmp'
f = None
try:
with open(tmpfile, 'wb') as f:
# 下载逻辑...
pass
# 验证成功后才重命名
os.rename(tmpfile, url.split('/')[-1])
except Exception:
raise
finally:
# 确保临时文件被清理，不管上面是否成功
if os.path.exists(tmpfile):
os.unlink(tmpfile)容易被忽略的释放陷阱
资源释放不是“写了 close() 就完事”，关键在「何时调用」和「是否真生效」。
- 文件对象被赋值给多个变量，只关一个不代表资源释放（引用计数未归零）
- 使用
io.StringIO或BytesIO时调用close()会使其不可再读，但不关也不影响内存回收（只是习惯问题） -
__del__不可靠，不能替代finally或with，GC 时机不确定，且异常中可能不执行 - 多线程下共享资源（如全局缓存），
finally里释放前要确认当前线程拥有该资源
最稳妥的做法：优先用 with，复杂流程补 finally，所有手动释放操作加 if not xxx.closed: 判断。
