Python weakref.finalize 如何安排资源兜底回收：回调存活与解释器退出边界

服务进程里有一类资源很难只靠业务主流程收干净：临时文件句柄、第三方客户端的底层连接、异常路径上来不及进入 finally 的辅助对象。weakref.finalize 可以为这类对象登记一个兜底动作，但它不是“更可靠的析构函数”：回调什么时候执行、能否在退出阶段执行，以及回调里是否误抓住目标对象，都要按规则设计。

把 weakref.finalize 当作资源清理的最后一道保险；正常业务路径仍用 with 或显式 close()，并让 finalizer 回调只接收独立的资源句柄或标识。

先把角色分清：目标对象、finalizer 和真正的资源

weakref.finalize(obj, func, *args, **kwargs) 注册的是一个独立的 finalizer 对象。它弱引用观察 obj，而 finalizer 自己会保持存活；当目标对象不再可达时，回调会以注册时提供的参数执行。下面的例子用文件描述符作为资源，回调只保存整数句柄，不保存 Handle 实例。

import os
import weakref

class Handle:
    def __init__(self, path):
        self.fd = os.open(path, os.O_RDONLY)
        self._finalizer = weakref.finalize(self, os.close, self.fd)

handle = Handle("/tmp/report.txt")
print(handle._finalizer.alive)
del handle

这里的调用链是 Handle 实例变得不可达，随后 finalizer 调用 os.close(fd)。如果把 self 作为回调参数传进去，finalizer 就会通过自己的参数链反向保留实例，兜底动作反而阻止了回收。

回调怎么写：只带资源，不带拥有者

最容易踩中的坑不是回调语法，而是引用关系。绑定方法通常带有隐含的实例引用，闭包也可能捕获外层对象。资源清理函数应尽量是模块级函数、静态函数或只接收独立值的可调用对象。

def close_fd(fd):
    try:
        os.close(fd)
    except OSError:
        pass

class SafeHandle:
    def __init__(self, path):
        self.fd = os.open(path, os.O_RDONLY)
        self._finalizer = weakref.finalize(self, close_fd, self.fd)

    def close(self):
        if self._finalizer.alive:
            self._finalizer()

显式调用 finalizer 后，alive 会变成 False，再次调用不会重复执行回调。注意，这只是避免同一个 finalizer 重复触发；如果资源还被其他对象持有，仍需由资源本身的所有者负责协调。

业务已经接管时：用 detach 取消兜底动作

有些对象先由通用容器创建，之后把句柄移交给长期连接池。移交完成后继续保留旧 finalizer，会让新旧所有权都试图关闭同一个资源。此时可以用 detach() 取回注册信息，并确认 finalizer 不再存活。

resource = SafeHandle("/tmp/report.txt")
func, args, kwargs = resource._finalizer.detach()
assert resource._finalizer.alive is False

# 所有权已经交给 manager，manager 保存回调数据并决定何时调用
manager_resources = {}
manager_resources[args[0]] = (func, args, kwargs)

detach() 返回原先登记的对象、可调用对象、位置参数和关键字参数；它不是“立即清理”，而是把自动触发权收回到业务代码。这个动作应紧跟所有权转移，否则中间窗口仍可能让旧拥有者被回收。

从 finalizer 的状态看，取消登记后可以把结果理解为 alive=False：后续由 manager 持有回调数据并负责资源协议，而不是让旧的 SafeHandle 再次自动关闭。

退出阶段的边界：atexit 不是可靠的业务事务

finalizer 默认参与正常解释器退出，但可以通过 finalizer.atexit = False 禁止它在退出阶段执行。即使保持默认值，也不能把它当作提交订单、刷新日志或完成网络确认的机会：解释器关闭时模块全局变量可能已被清理，进程被强制终止时也没有保证。

resource = SafeHandle("/tmp/report.txt")
resource._finalizer.atexit = False

import atexit
atexit.register(lambda: print("只处理进程级收尾，不依赖 resource"))

短生命周期脚本可以接受正常退出时的兜底关闭；服务进程则应把关闭动作放进信号处理、服务生命周期或 with 块，finalizer 只处理遗漏路径。

一套实际可用的决策顺序

1. 资源有明确作用域时，先用 with 或显式 close()，让成功路径可验证。
2. 对象可能在异常路径提前失去引用时，再注册只携带独立资源值的 finalizer。
3. 所有权转移前调用 detach()，把回调数据交给新的资源管理者。
4. 测试中同时覆盖显式关闭、对象回收、重复调用和解释器正常退出；不要只断言回调曾经被注册。

常见问题

weakref.finalize 会马上执行吗？

不会。它通常在目标对象不可达后执行，具体时机受实现和引用关系影响。需要确定时机的关闭动作应放在 with 或显式方法里。

为什么 finalizer 回调里不能用 self？

回调、闭包或绑定方法若直接或间接保存目标对象，会形成从 finalizer 到目标对象的强引用链，目标对象就可能一直可达，回调也不会按预期触发。

detach 后资源会自动关闭吗？

不会。detach() 取消自动触发并返回回调信息；新的所有权方必须自行决定何时调用回调或采用自己的关闭协议。

finalize 能替代 contextlib 吗？

不能。上下文管理器适合表达确定性资源边界，finalize 适合遗漏路径的兜底。把两者组合起来，通常比单独依赖 finalizer 更容易验收。

总结

weakref.finalize 的价值在于给“对象意外消失”留一条资源回收后路，而不是改变资源所有权模型。回调只接收独立句柄，显式关闭后检查 alive，移交资源前用 detach()，退出阶段不承诺业务事务；这四条边界能挡住大多数误用。