Python asyncio.create_task 取消后为什么还在跑：从引用丢失到任务收尾的故障复盘

线上接口已经返回超时，日志里的“同步库存任务”却还多跑了几十秒，甚至把已经取消的订单状态写回数据库。这个现象在Python asyncio里很常见：asyncio.create_task() 创建出来的是独立调度的任务，父协程结束并不会自动把它连带收尾；而 cancel() 也不是能直接把任务掐断的强制终止指令。

只要创建完任务就随手丢弃引用，就算你调用了cancel方法，任务也完全可能跑完所有业务逻辑，把脏数据写到库里。

超时之后，为什么还能看到后台写入

这类故障一般都起源于写法很随意的请求处理函数：收到请求就随手创建后台任务，设置两秒等待时长，客户端超时之后直接返回错误响应，但后台任务本身还一直持有数据库连接和完整的订单编号上下文。

async def handle_order(order_id):
    asyncio.create_task(sync_inventory(order_id))
    return await wait_for_result(order_id, timeout=2)

这里的问题根源从来不在 create_task 本身，而是创建出来的任务对象没有被任何地方保存。等到请求超时的分支逻辑想找它的时候根本找不到，自然也就没机会发取消指令、等它收尾、记录最终运行状态。垃圾回收机制不是业务级的任务管理器，绝对不能把它当成默认的任务收尾方案。

把故障时间线拆成三个可核对的状态

排查问题的时候先核对三个关键时间点：任务是什么时候创建的、请求是什么时候触发超时的、任务最后是什么时候真正结束的。只看到“请求超时”这一条日志，完全不能证明后台的业务逻辑已经停止运行。

• 创建：打日志的时候带上任务名称、关联的业务订单号和精确创建时间，别只打印一句模糊的“开始同步”就完事。
• 取消：超时分支里主动调用 task.cancel()，这一步只是往任务的上下文里注入一个取消标记而已。
• 收尾：再次执行 await task，捕获取消抛出的异常，确认数据库连接、临时文件、分布式锁这类资源都已经正常释放。

如果协程当时正在执行纯Python同步计算，或者在不对的位置捕获了取消异常，它完全可能继续运行很长一段逻辑。遇到这种情况别忙着下结论，先把任务状态、异常调用链、所有产生副作用的操作日志放到同一条链路追踪ID里核对。

最小修复：保存任务并等待取消完成

请求超时之后，父协程理应负责发出取消指令并等待任务执行完收尾逻辑。下面的写法主动保留了任务引用，也让整个清理路径有明确的执行入口。

import asyncio

async def sync_inventory(order_id):
    try:
        await asyncio.sleep(10)
        print("write inventory", order_id)
    except asyncio.CancelledError:
        print("inventory task cancelled", order_id)
        raise
    finally:
        print("release resources", order_id)

async def handle_order(order_id):
    task = asyncio.create_task(sync_inventory(order_id), name=f"inventory:{order_id}")
    try:
        await asyncio.wait_for(asyncio.shield(task), timeout=2)
    except asyncio.TimeoutError:
        task.cancel()
        try:
            await task
        except asyncio.CancelledError:
            pass
        return "timeout and cleaned"
    return "ok"

shield 的作用是避免 wait_for 自动替父协程取消任务；这样超时分支可以统一记录取消原因，主动调用 cancel 之后再等待任务完全跑完。如果业务本身要求请求超时之后任务也必须继续跑完，那就不要执行取消操作，直接把任务转交给有独立生命周期的后台worker组件，给它补上幂等校验和重试边界。

最容易漏掉的两个边界

不要把 CancelledError 当普通异常吞掉

如果只记录一句日志就不再把异常往外抛，上层调用方会误以为任务已经正常执行结束。资源清理逻辑放在 finally 里执行，取消分支做完必要的记录之后重新抛出异常，调用方才能准确区分“任务被主动取消”和“任务正常执行完成”两种状态。

取消不能撤销已经发生的外部写入

如果数据库更新操作已经完成提交，取消指令只会阻止任务后续代码运行，完全没法回滚已经提交的这次变更。库存、支付、发货这类核心操作必须使用幂等键、状态机或者明确的事务边界做保护；取消日志只能证明任务已经停止运行，不等于业务数据会自动恢复到正确状态。

上线前用日志确认任务真的收尾

建议至少要记录任务名、关联业务主键、取消触发原因、最终结束状态和整体耗时。测试的时候把 asyncio.sleep(10) 换成很短的等待时长，断言超时之后绝对不会出现“write inventory”这类写入日志，同时检查 finally 的资源清理记录一定会打印出来。

result = await handle_order("order-1042")
assert result == "timeout and cleaned"

如果后台任务的总数量持续上涨，可以定期统计 asyncio.all_tasks() 里的任务名做趋势排查，但不要在生产环境频繁打印所有任务的完整调用堆栈。更稳妥的方案是给任务创建入口做统一封装，集中保存任务实例、设置任务名称、统一处理异常和执行回收逻辑。

常见问题

调用 task.cancel() 后任务会立即停止吗？

不会。asyncio的取消是协作式的取消请求，任务要运行到能响应取消事件的挂起点才会处理标记，调用方还必须主动等待任务结束才算完整流程。

为什么要重新抛出 CancelledError？

这样上层调用方才能明确知道任务是被主动取消的，而不是正常跑完结束；否则超时、取消、运行成功三种状态会被混成同一种结果，根本没法做后续逻辑判断。

超时后是否一定要取消任务？

不一定。运行时长很短的事务性任务通常应当取消并回收资源；必须跑完的重要工作应该移交给专门的后台组件托管，用幂等和状态校验机制保护外部写入的安全性。

收尾检查

排查asyncio后台任务异常的时候，先找任务实例的引用链路，再核对取消请求的发出位置，最后以 await 之后打印的任务结束日志作为判断依据。只要任务管理、异常传播、外部写入三个边界都理清楚，接口超时就不会再悄悄变成一条失控的后台写入链。