Python 3.14 asyncio ps 怎么排查卡住任务：PID、任务栈与 pstree 验收

线上Python服务出现请求一直不返回的情况，先别急着给进程发信号或者重启容器。Python 3.14自带的asyncio命令行检查工具可以附着到正在运行的进程上，直接列出任务名、协程栈和等待链：ps 适合快速筛选全量任务表，pstree 适合沿着父子任务关系一步步找出阻塞点。

排查顺序可以固定下来：先确认目标PID，再用 python -m asyncio ps PID 查看平面任务表，最后用 python -m asyncio pstree PID 沿等待关系定位根因。两条命令都只会读取现场数据，完全不能替代应用本身预设的超时、取消和异常恢复逻辑。

先判断：问题是进程整体卡住，还是某一个asyncio任务在正常等待

接口长时间无响应，并不代表整个Python进程已经失去响应。事件循环可能还在正常运转，只是其中一个任务一直卡在等数据库连接、网络响应、分布式锁或者另一个未返回的子任务的状态上。反过来如果进程本身已经退出终止，检查命令也不可能凭空还原出已经消失的历史现场。

所以第一步只做进程身份确认，千万别在错误的容器或者不对的Python环境里乱执行检查命令：

ps -ef | grep '[p]ython.*worker.py'
python --version
python -m asyncio --help

最终目的是拿到正在运行业务逻辑的Python进程号，比如 24680，同时确认发起检查的解释器版本至少是3.14。生产环境如果业务应用用了虚拟环境，检查命令最好也用同一个虚拟环境里的Python解释器来发起。

用asyncio ps先查看平面任务全表

拿到正确PID之后，先执行下面的命令：

python -m asyncio ps 24680

官方给出的示例输出里包含任务编号、任务名、协程栈、等待者链以及等待者的名称和编号。你不需要提前通读全部业务代码，就能把当前有哪些存活任务、这些任务各自停在什么协程执行路径这两个信息分开梳理。

读输出的时候可以先找业务任务名称，比如 order-sync、load-profile 或者 worker-7，再顺着看协程栈的最末端位置。如果多个任务都停在同一个外部调用附近，通常说明它们的共同依赖需要优先排查；如果只有单个任务卡住，就先回溯这个任务持有的资源和它的异常取消路径。

用asyncio pstree沿等待链确认阻塞根节点

平面任务表适合快速筛选，层级树结构适合理清任务之间的依赖关系：

python -m asyncio pstree 24680

树形输出会把任务之间的等待关系完整展开。一个父级 TaskGroup 下面可能挂载了好多个业务子任务；如果父级在等待所有子任务退出，而子任务本身还停在 sleep、网络读取或者数据库调用的位置，真正需要定位的是子任务的等待点，而不是父级的收尾栈。

可以把当前现场记录成三列内容：任务名、当前协程栈、等待对象。后续重启进程或者现场恢复之后，你仍然可以把这些观察结果交给负责连接池、RPC客户端或者任务编排的同事复盘问题。

按输出结果做三次快速判断

版本、权限和现场边界说明

这组命令完全依赖Python 3.14新增的asyncio检查入口。先运行 python --version 确认环境，再用业务应用实际使用的解释器发起检查；如果系统里同时安装了多个Python版本，python 指向的版本很可能和服务启动时用的解释器版本不一样。

执行检查的进程通常还会受到容器隔离和用户权限规则的限制。如果命令无法读取目标PID，先确认自己是否进入了同一个容器、同一个进程命名空间，同时保留好错误提示文本；不要为了临时查看任务状态就随意扩大生产环境的操作权限。命令输出里也可能包含业务路径、任务名或者参数标识这类敏感内容，保存到工单的时候要按照现有日志脱敏规则做处理。

把一次现场检查变成可回归的修复方案

ps 和 pstree 解决的只是“这一刻到底是谁在等什么”的问题。真正的修复还是要落到代码层面：给所有外部I/O操作设置明确的超时时间；让取消信号可以正常传递到所有子任务；在 TaskGroup 退出的时候主动释放连接、锁和临时文件；为每个业务任务设置稳定的自定义名称，同时把请求标识写入日志上下文。

后续做功能演练的时候，可以故意写一个测试任务让它长时间等待，再用这两条命令确认它从任务表到等待树都可以被正常识别。验收标准不是输出看起来内容很多，而是你能明确回答三个问题：哪个任务卡住了、它在等什么资源、修复之后任务能不能按预期正常退出。

常见问题

Python 3.13 可以直接运行 asyncio ps 吗？

不要默认它可以运行。这是Python 3.14的新命令行能力，要先确认实际使用的解释器版本，所有功能说明以对应版本的官方帮助和文档为准。

ps 和 pstree 应该先使用哪个？

先用 ps 做平面筛选，再用 pstree 展开等待关系。当任务总量很多的时候，这样操作比一开始就直接通读整棵树效率高很多。

看到任务处于等待状态就等于出故障了吗？

当然不是。异步任务本身的特性就是会等待I/O或者子任务返回；核心判断点是等待时长有没有超过业务预设的时限、是否有大量任务共同卡在同一个依赖上，以及任务收到取消信号之后能不能正常完成收尾。

这两个检查命令能自动修复卡住的任务吗？

不能。它只会提供只读的诊断信息，问题修复还是要处理超时配置、任务取消、资源释放和外部依赖健康度这些相关逻辑。

下次再遇到异步请求长时间不返回的情况，先留存好PID、解释器版本和两条命令的输出结果，再顺着任务名和等待链把问题交给对应依赖的负责人处理。这样一次偶发的卡顿问题才能变成可以后续复查的工程证据。