Python atexit 注销重复回调：只调用一次 unregister，为什么两份清理任务都消失了
插件初始化时把同一个清理函数注册了两次，只是给它传入不同标签。后来其中一个插件要取消清理，调用一次unregister之后，两份回调都没有执行。这里不能用“删除最后加入的一项”来理解注销接口：它的匹配对象是函数，而不是某一次带参数的登记。理解这一点，才能避免多个组件互相撤掉退出工作。
本文在Linux、Python 3.12.14中使用固定样本实跑。官方文档核验于2026年10月3日；在线文档显示的补丁版本可能不同于这里记录的实际解释器。程序不访问真实业务数据，也不连接远程服务。
AI模型生成的原创概念图：清理票据按后进先出离场，同类重复票据被一起撤除；用于解释程序模型，不是软件截图、测试截图或实拍照片，精确行为以程序和实际输出为准。
完整程序与实际输出
将下面程序保存为tech11.py，执行python tech11.py。预期出现的异常已在例子里处理；退出码为零才表示本次演示正常完成。
import atexit
def cleanup(label):
print("cleanup", label)
def keep(label):
print("keep", label)
atexit.register(keep, "first")
atexit.register(cleanup, "A")
atexit.register(keep, "last")
atexit.register(cleanup, "B")
atexit.unregister(cleanup)
print("body done")本次实际标准输出：
body done keep last keep first
输出顺序如何对应登记过程
程序先登记keep(first)，再登记cleanup(A)，然后登记keep(last)和cleanup(B)。普通主体只打印body done，后面的输出发生在解释器正常终止阶段。实际结果是keep last、keep first，正好是剩余登记项的逆序；没有cleanup A，也没有cleanup B。
这份测试需要以独立脚本运行，而不是只把定义粘贴到仍然继续工作的交互会话中。交互会话未退出，退出回调自然还没轮到执行。测试框架若复用一个解释器，也可能让多个用例的登记累积在一起。因此验收退出流程时，短生命周期子进程通常比在一个长期驻留进程里反复注册更容易隔离。
注销针对函数，不区分那次登记的参数
cleanup虽然以A和B两个标签登记，传给unregister的仍是同一个cleanup函数。注销会移除匹配该函数的所有登记项，不会根据参数替你定位其中某一笔。本例刻意只调用一次unregister；随后正常退出时，两个cleanup标签都没有出现，而两条keep回调仍执行。这才能直接区分“一次移除全部匹配登记”与“一次只移除一项”。
如果业务确实需要独立取消两个动作，可以为每次动作保存不同的包装函数或不同partial对象，并保留各自引用。设计时仍要留意注销使用相等比较而不仅是身份比较，自定义可调用对象若重写了相等规则，可能扩大匹配范围。给组件分配清晰的回调句柄，比让所有组件共享一个总清理函数更容易管理。
后进先出适合有依赖关系的收尾
一个底层服务先初始化，上层功能后初始化；退出时先拆掉上层，再拆底层，通常更符合依赖关系。因此逆序可以是有用的默认安排。但它依赖实际登记顺序，模块导入变化也可能改变顺序。若清理依赖十分关键，应把顺序写在一个明确的关闭流程里，不要把业务正确性寄托在隐蔽的导入先后上。
本例的回调只输出文字，没有网络发送、文件覆盖或其他外部副作用。真实回调应尽量短小，并预先考虑重复关闭、资源已经失效和日志输出失败等情况。退出阶段再启动复杂工作会增加不可预测性，特别是Python 3.12已对回调中启动新线程或fork做出限制，不能把退出钩子当成新的任务调度入口。
退出钩子不能代替正常的资源管理
atexit主要面向解释器的正常终止流程。进程被无法处理的信号终结、解释器严重内部错误，或直接走os._exit等路径时，不能指望这些回调仍然执行。示例没有调用这些非常规出口，因为为了展示回调边界而故意制造异常终止，会让读者混淆运行失败与教程结论。
必须及时完成的文件刷新、事务提交和业务确认，应在正常控制流中完成；局部资源优先用with或try/finally。atexit可以补充普通退出时的收尾，但不能替应用提供持久性保证。给退出测试列一张可见清单：正常路径的执行顺序、重复登记的归属、独立取消需要的句柄，以及哪些异常终止情形明确不保证执行。
验证记录与参考资料
本次完整程序退出码为0，标准错误为空。本次验证正常退出路径中一次注销移除两条匹配登记，以及剩余回调的逆序执行；不保证异常终止时仍会运行退出钩子。
