Python Textual Worker取消后怎样处理清理逻辑

Textual 的 Worker 被取消后，清理逻辑不应只写在 Worker.StateChanged 事件里。正确的分工是：异步 Worker 在协程内部用 try/finally 释放连接、文件或临时对象，必要时捕获 asyncio.CancelledError 做少量记录后继续抛出；线程 Worker 则通过 get_current_worker().is_cancelled 在安全检查点主动退出。状态事件只负责更新界面，不替代资源回收。

官方地址：https://textual.textualize.io/guide/workers/

把取消看成一次生命周期变化，而不是普通业务异常：先让任务停止产生新结果，再确保资源释放，最后把加载状态还原给界面。

先分清两种 Worker 的取消语义

Textual 的 @work 和 run_worker 可以运行协程，也可以把普通函数放进线程。两者都能调用 Worker.cancel()，但底层行为不同。

协程 Worker 收到取消请求后，事件循环会在合适的挂起点注入 CancelledError，所以 async with、finally 这类 Python 资源管理结构仍然有机会完成收尾。线程 Worker 没有同样的强制中断机制，取消更像是给正在运行的函数设置一个可观察的标记；正在执行的阻塞调用可能还会继续一段时间。

import asyncio
from textual import work

class ReportScreen:
    @work(group="report", exclusive=True, exit_on_error=False)
    async def refresh_report(self, report_id: str) -> None:
        # async Worker 的取消会在挂起点表现为 CancelledError。
        try:
            async with open_report_session(report_id) as session:
                await session.fetch_summary()
                await session.fetch_rows()
        except asyncio.CancelledError:
            # 这里只记录或更新可取消状态，不要吞掉取消信号。
            self.log(f"report {report_id} cancelled")
            raise
        finally:
            # async with 已负责会话释放；其它独立资源也应在这里收尾。
            self.log(f"report {report_id} cleanup finished")

这里的 exclusive=True 还解决了“旧请求晚于新请求返回”的问题：同组新 Worker 启动时会取消旧 Worker。不要把 CancelledError 改成成功结果，否则旧任务仍可能继续更新界面。

异步资源统一放进 finally，状态事件只管界面

最稳妥的清理边界是“谁申请资源，谁在同一层释放”。网络客户端、临时文件、数据库游标等对象优先使用上下文管理器；无法使用上下文管理器时，在 finally 中显式关闭。取消分支可以记录原因，但要重新抛出取消异常，让 Textual 把 Worker 归入 CANCELLED。

from textual.worker import Worker, WorkerState

class ReportScreen:
    def on_worker_state_changed(self, event: Worker.StateChanged) -> None:
        # 状态事件负责复位按钮、进度条等 UI 状态，不负责关闭连接。
        if event.state in {WorkerState.CANCELLED, WorkerState.ERROR, WorkerState.SUCCESS}:
            self.set_loading(False)

    def cancel_report(self) -> None:
        # 保存 run_worker 或装饰器调用返回的 Worker，取消当前任务。
        if self.current_worker is not None and not self.current_worker.is_finished:
            self.current_worker.cancel()

事件处理器适合把“加载中”改回“可操作”，也适合显示取消提示。资源清理却应该在 Worker 本身的执行函数中完成，因为节点销毁、应用退出和手动取消都可能触发同一条收尾路径。若在事件处理器里再次访问已经移除的控件，还要考虑 DOM 生命周期。

可以用下面的关系检查设计是否完整：Worker 内部有资源，就必须有 finally 或上下文管理器；需要更新界面，就监听状态事件；需要取消，就保留 Worker 引用；需要避免旧结果覆盖新结果，就按同一 group 使用 exclusive=True。

线程 Worker 要在安全检查点主动停下

当依赖库只有同步接口时，可以用 thread=True。但取消线程不会像取消协程那样立刻打断正在运行的函数，Textual 官方建议在函数中取得当前 Worker，并检查它的取消标记。

from textual import work
from textual.worker import get_current_worker

class FileScreen:
    @work(group="scan", thread=True, exit_on_error=False)
    def scan_files(self, paths: list[str]) -> None:
        worker = get_current_worker()
        opened = []
        try:
            for path in paths:
                # 每次处理前检查取消标记，避免继续打开新的文件。
                if worker.is_cancelled:
                    break
                handle = open(path, "rb")
                opened.append(handle)
                inspect_header(handle)
        finally:
            # 无论完成、异常还是取消，都关闭已经打开的文件。
            for handle in opened:
                handle.close()

        if worker.is_cancelled:
            return
        # 线程不能直接改 UI，结果要切回 Textual 主线程。
        self.app.call_from_thread(self.show_scan_done)

这段代码的关键不是“检查一次就能立即终止”，而是把检查点放在可控的工作边界上。若某个同步调用本身很长，应优先给它增加超时、拆成较小批次，或换成支持异步取消的接口。线程结束前不要把半成品结果发送给界面，否则取消后仍可能出现旧结果覆盖新状态。

用四个检查点确认清理逻辑没有漏

最常见的两个坑是：在 except Exception 里把取消转换成普通失败，或者在线程 Worker 里直接操作控件。前者会让调用方误以为任务失败或成功，后者可能造成线程安全问题。把资源生命周期留在 Worker，把 UI 生命周期留在状态事件，取消后的行为就会更容易复查。

相关问题

Worker.cancel() 会立即杀掉线程吗？

不会。线程 Worker 需要自己轮询 get_current_worker().is_cancelled，正在执行的阻塞调用仍可能继续，直到函数到达可退出的检查点。

捕获 CancelledError 后为什么还要 raise？

因为捕获通常只是为了记录、回滚或更新少量状态。重新抛出才能保留取消语义，让 Textual 正确记录 Worker 的 CANCELLED 状态。

状态事件能不能代替 finally？

不能。状态事件适合刷新界面；连接、文件和临时对象的释放应放在 Worker 执行函数的上下文管理器或 finally 中。