Python 3.15 asyncio REPL 怎样处理启动脚本异常

我在把几个异步小工具搬到 Python 3.15 的交互环境时，最容易误判的一点不是 await，而是启动脚本到底有没有被读取。python -m asyncio 的 REPL 在可用 PyREPL 时会执行 PYTHONSTARTUP，但隔离选项和不同的启动入口会改变这个前提。启动脚本一旦在导入或初始化阶段抛出异常，排查重点就应该从“asyncio 是否坏了”转向“哪个初始化边界失败了”。

官方资料入口：https://docs.python.org/3.15/library/asyncio.html。下面我把问题压缩成 3 类启动入口、2 个隔离选项和 1 个异常边界，方便快速判断为什么异常没有按预期显示。

先分清 asyncio REPL 的启动入口

先记住一个容易被忽略的事实：python -m asyncio 是带有异步上下文的交互入口，可以直接使用 await；它不是把普通 REPL 外面简单包一层。Python 文档还说明，这个入口对 PYTHON_BASIC_REPL 的兼容是有限的，默认 REPL 通常更适合体验完整的交互特性。

我排查时会先把启动方式分成三类：

PYTHONSTARTUP 只在交互模式下读取可读文件，文件中的对象会进入交互会话命名空间。它不是所有 python 命令都会自动执行的项目初始化器；脚本、-c 和 -m 的行为要分别看启动路径。

让 PYTHONSTARTUP 的异常信息可读

启动脚本适合放轻量的导入、快捷函数和诊断开关，不适合把大量业务初始化塞进去。为了让异常显示有上下文，可以把可能失败的部分收在一个函数里，并在入口处保留异常类型和原始回溯：

# startup_async.py：只放交互式诊断辅助，不启动长期后台任务。
import os
import sys
import traceback

def load_async_helpers():
    # 这里的导入失败会被入口捕获，便于区分环境问题和 REPL 问题。
    import asyncio

    def show_runtime():
        # 输出少量稳定信息，帮助确认当前会话和环境变量状态。
        print("python:", sys.version.split()[0])
        print("startup:", os.environ.get("PYTHONSTARTUP", ""))
        return asyncio

    return show_runtime

try:
    show_runtime = load_async_helpers()
except Exception:
    # 保留完整回溯；不要把启动异常改写成模糊的“初始化失败”。
    traceback.print_exc(file=sys.stderr)
    show_runtime = None

这里的关键不是“吞掉异常”。如果启动脚本失败，完整回溯仍然应该出现在标准错误中；设置 show_runtime = None 只是让交互会话有一个明确的失败状态，避免后续输入引用一个根本不存在的名称。

如果你更希望启动失败就立即结束，应该让异常继续向外抛出，并把它当作脚本启动失败处理；如果你希望保留 REPL 现场，则可以像上面这样在入口处打印回溯后提供一个可检查的哨兵值。两种选择都比裸露的顶层导入更容易定位。

在 asyncio REPL 中保留诊断现场

asyncio REPL 的价值在于可以直接执行 await。因此，启动脚本异常后不要马上重启很多次，而是先确认几个事实：启动脚本是否被读取、辅助函数是否存在、当前环境变量是否可见。下面的检查命令只读状态，不改变项目文件：

# 在 python -m asyncio 中执行：这些语句只检查当前交互命名空间。
import os
import sys

print("interactive:", hasattr(sys, "ps1"))
print("startup value:", os.environ.get("PYTHONSTARTUP", ""))
print("helper ready:", "show_runtime" in globals())

if "show_runtime" in globals() and show_runtime is not None:
    runtime_asyncio = show_runtime()
    # 直接 await 一个最小协程，确认当前确实是 asyncio REPL。
    await runtime_asyncio.sleep(0, result="asyncio-repl-ready")

最后一行的结果只能说明当前会话允许直接 await，不能证明所有启动脚本逻辑都正确。把“入口可用”和“初始化成功”分开记录，才能避免看到一个正常的异步结果就误以为启动脚本没有异常。

用三组场景收口排查

我通常只保留三组对照，足以覆盖标题里的大多数“为什么没有显示”问题：

1. 入口对照：分别确认普通交互模式与 python -m asyncio。如果前者能看到启动脚本中的对象、后者没有，优先查 PyREPL 条件和 asyncio REPL 的兼容边界。
2. 隔离对照：检查是否使用了 -E 或 -I。Python 文档明确说明，隔离模式会忽略 PYTHON* 环境变量；此时继续修改 shell 中的 PYTHONSTARTUP 不会改变当前解释器行为。
3. 脚本对照：把启动文件缩小到一个确定成功的导入和一个确定失败的导入，比较标准错误中的回溯。若最小脚本能显示异常，再逐段加回初始化代码，问题通常就在最近加入的导入或副作用。

这三组对照的结果可以整理成一个简单判断：入口不同，先看是否读取；参数不同，先看环境变量是否被忽略；脚本不同，先看异常是否被捕获、改写或在导入之前就终止了。不要用“REPL 没报错”反推启动脚本一定执行成功。

两个容易混淆的问题

asyncio REPL 里直接写 await，还需要 asyncio.run() 吗？ 不需要把交互式测试强行包进 asyncio.run()；该 REPL 的设计就是允许直接等待协程。独立脚本仍然可以使用适合脚本入口的事件循环管理方式，两者不要混为一谈。

为什么设置了 PYTHONSTARTUP 却看不到异常？ 先确认当前是不是交互模式，再检查是否启用了 -E 或 -I。此外，Python 3.13 起，使用 PyREPL 时 asyncio REPL 才会执行 PYTHONSTARTUP；如果入口退回其他 REPL 实现，行为可能不同。

我的结论是：把问题拆成 3 类入口、2 个隔离选项和 1 个脚本异常边界，通常比反复重启更快。先确认脚本有没有被读取，再确认环境变量有没有被解释器忽略，最后才处理具体导入或初始化代码；这样既保留了 asyncio 的直接 await 体验，也不会把启动脚本问题误判成事件循环问题。