1. 为什么错误偏偏挑跑完之后才现身写过异步代码的人大概都经历过这种诡异时刻程序主体逻辑跑得好好的日志一行行刷得飞起结果最后收尾阶段突然甩出一个RuntimeError或者浏览器控制台在页面都快关掉的时候蹦出一句Uncaught TypeError: Cannot read properties of undefined (reading writeText)。更让人抓狂的是这类报错往往复现不稳定有时候跑十次只出现一次有时候换个机器就再也见不到。这个现象背后其实有一个非常统一的解释错误不是跑完之后才产生的而是跑完之后才被暴露出来的。程序在运行期间很多异步任务、事件回调、资源清理动作都处于挂起或排队状态它们的结果没有被立即消费。等到主流程结束、事件循环准备收尾时这些被积压的异常才集中浮出水面。换句话说你看到的报错时间点是异常被结算的时间点而不是它被制造的时间点。理解这一点非常关键因为它直接决定了排查方向。如果你盯着报错那一行代码去找问题大概率会一无所获因为那一行可能只是无辜的收尾代码。真正的病灶藏在更早的某个异步调用、某个未捕获的 Promise、某个没被 await 的任务里。这篇文章会围绕几个高频关键词展开RuntimeError、事件循环、asyncio、run_sync、TypeError以及热搜里出现的runtimeerror: unexpected error from cudagetdevicecount()和 JS 侧的writeText报错。我会把跑完之后才报错这个现象拆成几类典型场景讲清楚每一类的根因、排查链路和修复方案并且给出可以直接抄作业的代码。无论你是写 Python 异步、做前端交互还是碰深度学习框架这套思路都能用得上。2. 事件循环收尾阶段的异常结算机制2.1 事件循环到底在跑完之后做了什么要理解跑完之后报错先得理解事件循环的生命周期。以 Python 的asyncio为例一个典型的事件循环大致经历这么几个阶段创建、运行任务、任务队列清空、取消剩余任务、关闭执行器、关闭循环。很多人只关注运行任务这一段却忽略了后面几个阶段而报错恰恰经常发生在取消剩余任务和关闭这两个阶段。当主协程main()返回后事件循环并不会立刻消失。它会检查是否还有挂起的任务pending tasks。如果有它会尝试取消它们并等待它们响应取消请求。这个取消—响应—清理的过程就是异常集中爆发的窗口。一个任务在被取消时如果它的finally块里有代码抛异常或者它本身吞掉了一个异常没处理这个异常就会在这个阶段被抛出。用一个生活化的类比事件循环像是一个项目经理主流程是白天的正常工作收尾阶段是下班前的清场。白天大家各忙各的有些问题被暂时压着没爆等到清场时项目经理挨个检查那些被压着的问题就一个个冒出来了。所以跑完之后报错本质上是清场阶段的集中审计。2.2 未 await 的协程与孤儿任务最常见的元凶之一是创建了协程却没有 await也没有放进任务队列。看这段代码import asyncio async def fetch_data(): raise RuntimeError(数据源连接失败) async def main(): fetch_data() # 注意这里没有 await print(主流程结束) asyncio.run(main())运行结果会打印主流程结束然后抛出一个RuntimeWarning: coroutine fetch_data was never awaited。注意这里抛的是警告而不是异常因为那个协程压根没被执行异常也就没被触发。但如果换成asyncio.create_taskimport asyncio async def fetch_data(): raise RuntimeError(数据源连接失败) async def main(): asyncio.create_task(fetch_data()) print(主流程结束) asyncio.run(main())这时候fetch_data会被真正调度执行异常会在事件循环收尾时以Task exception was never retrieved的形式冒出来。报错信息里会明确写着任务异常从未被获取这就是典型的跑完之后才报错。提示asyncio.create_task创建的任务如果异常没有被 await 或 add_done_callback 消费异常会被暂存直到任务对象被垃圾回收时才打印。这就是为什么报错时机飘忽不定——它取决于垃圾回收的时机。2.3 取消传播中的二次异常第二类场景是任务取消过程中的异常。当事件循环关闭时它会向所有 pending 任务发送CancelledError。如果某个任务的finally块或except块在处理取消时又抛了新异常这个新异常会覆盖掉取消信号导致收尾阶段报错。import asyncio async def worker(): try: await asyncio.sleep(100) finally: # 清理逻辑本身出错 result 1 / 0 async def main(): task asyncio.create_task(worker()) await asyncio.sleep(0.1) asyncio.run(main())这段代码在main结束后事件循环尝试取消worker触发finally块1/0抛出ZeroDivisionError。最终你会看到一个和CancelledError混在一起的异常堆栈非常难读。排查这类问题的诀窍是在finally块里做清理时一定要用 try/except 包住绝不能让清理逻辑本身抛异常。2.4 执行器线程池的延迟报错还有一类容易被忽略的场景run_in_executor提交到线程池的任务。线程池里的任务如果抛异常异常会被保存在 Future 里只有当你 await 这个 Future 时才会重新抛出。如果你提交了任务却没管它的返回值异常就会一直沉默直到解释器退出或者 Future 被回收。import asyncio def blocking_work(): raise RuntimeError(线程池任务失败) async def main(): loop asyncio.get_running_loop() loop.run_in_executor(None, blocking_work) print(提交完成) asyncio.run(main())这段代码会打印提交完成然后安静地结束异常被彻底吞掉。如果你在main里加一句await asyncio.sleep(1)让 Future 有机会被回收才可能看到异常。这种时有时无的表现正是跑完之后报错最折磨人的地方。3. run_sync 与同步桥接引发的收尾异常3.1 run_sync 的典型使用误区run_sync这类接口不同框架里名字可能不同比如loop.run_until_complete、asyncio.run、某些库提供的run_sync包装本质上是在同步代码里驱动异步逻辑。它的工作模式是创建一个事件循环把协程塞进去跑跑完关闭循环。问题就出在关闭循环这一步。一个非常经典的坑是在已经运行的事件循环里再调用run_sync。比如你在一个 async 函数里想调用一个同步接口而这个同步接口内部又调用了run_sync就会触发RuntimeError: This event loop is already running或者RuntimeError: asyncio.run() cannot be called from a running event loop。import asyncio async def inner(): return 42 def sync_wrapper(): return asyncio.run(inner()) # 危险在事件循环内调用 async def main(): result sync_wrapper() print(result) asyncio.run(main())运行后会直接报RuntimeError: asyncio.run() cannot be called from a running event loop。这个报错看起来是运行中抛的但很多变体会延迟到收尾阶段尤其是当sync_wrapper被放在回调或线程里执行时。3.2 嵌套事件循环的收尾陷阱更隐蔽的情况是嵌套事件循环。有些库为了兼容同步调用会在内部创建新的事件循环。如果外层循环还在运行内层循环关闭时可能会干扰外层的状态导致外层在收尾时报出莫名其妙的RuntimeError。排查这类问题的实用方法是在报错堆栈里找run_until_complete、run_forever、new_event_loop这些关键字。只要看到它们出现在非预期的位置基本就能锁定是嵌套循环问题。修复思路有三条统一异步边界尽量让异步逻辑在同一个事件循环里跑完不要在中间插入同步桥接。用asyncio.to_thread或run_in_executor替代同步桥接把同步调用放到线程里避免创建新循环。如果必须桥接用nest_asyncio之类的补丁仅限开发调试生产环境慎用或者干脆重构调用链。3.3 同步桥接中的资源泄漏run_sync还有一个常见副作用资源没被正确关闭。比如你在run_sync里打开了数据库连接、文件句柄、网络会话但协程因为异常提前退出finally块没执行完循环就关闭了。这些资源会在解释器退出时被强制回收回收过程中可能触发RuntimeError。我踩过的一个真实坑是用某个 HTTP 库的同步接口发请求底层其实是run_sync包装的异步客户端。当请求超时后客户端没被正确关闭等到程序退出时底层连接池的清理逻辑抛出了RuntimeError: Event loop is closed。这个报错出现在程序最后一行日志之后看起来像是跑完之后才发生的实际上是资源清理顺序错了。解决办法是显式管理生命周期。用async with或try/finally确保客户端被关闭并且关闭动作要在事件循环还活着的时候完成。import asyncio import aiohttp async def fetch(url): async with aiohttp.ClientSession() as session: async with session.get(url) as resp: return await resp.text() async def main(): try: data await fetch(https://example.com) print(len(data)) finally: # 确保所有清理动作在循环关闭前完成 await asyncio.sleep(0) asyncio.run(main())4. TypeError 在收尾阶段的几种典型面孔4.1 Cannot read properties of undefined 的时机问题前端热搜里那句Uncaught TypeError: Cannot read properties of undefined (reading writeText)是另一个维度的跑完之后报错。它的典型场景是页面主体渲染完成用户交互也正常但在某个异步回调比如剪贴板操作、定时器、事件监听器里访问了一个已经被销毁或尚未初始化的对象。writeText是剪贴板 API 的方法调用形式是navigator.clipboard.writeText(text)。如果navigator.clipboard在某些环境下是undefined比如非安全上下文、旧浏览器、或者被权限策略禁用就会报这个错。而它之所以跑完之后才出现是因为剪贴板操作通常绑定在按钮点击或异步流程末尾。async function copyToClipboard(text) { // 危险没有检查 clipboard 是否存在 await navigator.clipboard.writeText(text); }正确的写法应该加防御async function copyToClipboard(text) { if (!navigator.clipboard) { // 降级方案 const textarea document.createElement(textarea); textarea.value text; document.body.appendChild(textarea); textarea.select(); document.execCommand(copy); document.body.removeChild(textarea); return; } await navigator.clipboard.writeText(text); }4.2 事件循环里的 this 丢失JS 事件循环里另一个高频TypeError来源是this 绑定丢失。当你把一个对象方法作为回调传给setTimeout或addEventListener时方法里的this不再指向原对象访问this.someProperty就会得到undefined进而读取属性时报TypeError。class ClipboardManager { constructor() { this.text ; } write() { // this 可能不是 ClipboardManager 实例 navigator.clipboard.writeText(this.text); } } const manager new ClipboardManager(); setTimeout(manager.write, 1000); // this 丢失修复方式是用箭头函数或bindsetTimeout(() manager.write(), 1000); // 或者 setTimeout(manager.write.bind(manager), 1000);这类报错的特点是同步调用时正常一旦进入异步回调就崩。因为同步调用时this由调用方式决定而异步回调的调用者是事件循环this就变成了undefined或全局对象。4.3 异步流程中的对象生命周期错配还有一种情况是对象在异步流程中被提前销毁。比如你在组件挂载时发起请求请求返回后更新组件状态但组件在请求返回前已经被卸载。这时候访问组件实例的属性就会报TypeError。React 里经典的Cant perform a state update on an unmounted component就是这个问题的变体。处理原则是在异步回调里访问任何外部对象前先检查它是否还有效。可以用一个标志位也可以用 AbortController 取消未完成的请求。function useData() { const [data, setData] useState(null); useEffect(() { let cancelled false; fetchData().then(result { if (!cancelled) { setData(result); } }); return () { cancelled true; }; }, []); return data; }5. CUDA 初始化报错与跑完之后的关联5.1 cudagetdevicecount 报错的真实含义热搜里那条runtimeerror: unexpected error from cudagetdevicecount(). did you run some c...是深度学习框架里非常典型的报错。cudaGetDeviceCount是 CUDA 运行时 API用来查询可用 GPU 数量。这个报错通常意味着CUDA 运行时初始化失败或者 GPU 在程序运行期间变得不可用。它和跑完之后报错的关联在于很多框架会在程序退出时做设备清理清理过程中会再次调用 CUDA API。如果此时 GPU 已经被其他进程占用、驱动状态异常、或者上下文已经失效清理调用就会失败抛出这个RuntimeError。所以你看到的现象是训练跑完了模型保存了日志也正常结果退出时崩了。5.2 常见触发条件与排查顺序触发这个报错的条件大致有这么几类触发条件典型表现排查方法多进程同时初始化 CUDA子进程报错主进程正常检查 DataLoader 的 num_workers 设置显存不足导致上下文丢失训练中途或退出时报错用 nvidia-smi 观察显存占用驱动与运行时版本不匹配首次调用 CUDA 就报错核对驱动版本和框架要求的 CUDA 版本进程 fork 后复用 CUDA 上下文子进程报错避免在 fork 后直接使用 CUDA程序退出时清理顺序错误跑完后报错检查 atexit 钩子和析构函数排查顺序建议是先确认单进程单卡能否正常跑通再逐步加上多进程、多卡、数据加载器定位到具体是哪一步引入的问题。这个二分法思路在排查 CUDA 问题时特别有效因为 CUDA 报错信息往往很模糊靠猜是猜不出来的。5.3 多进程数据加载的经典坑PyTorch 的DataLoader在num_workers 0时会 fork 子进程。如果子进程里不小心触碰了 CUDA就会触发cudaGetDeviceCount报错。因为 CUDA 上下文不能跨 fork 安全共享。from torch.utils.data import DataLoader # 危险dataset 的 __getitem__ 里用了 CUDA class MyDataset: def __getitem__(self, idx): tensor torch.tensor([1, 2, 3]).cuda() # 子进程里调用 CUDA return tensor loader DataLoader(MyDataset(), num_workers4)修复原则很简单数据加载阶段只做 CPU 操作张量搬到 GPU 的动作放到主进程的训练循环里。class MyDataset: def __getitem__(self, idx): return torch.tensor([1, 2, 3]) # 保持 CPU for batch in loader: batch batch.cuda() # 主进程搬到 GPU # 训练逻辑5.4 退出阶段的清理顺序如果你的报错确实发生在程序退出时可以尝试显式控制清理顺序。比如在训练结束后先手动释放模型和优化器占用的显存再让程序自然退出。import torch import gc # 训练结束后 del model, optimizer gc.collect() torch.cuda.empty_cache()torch.cuda.empty_cache()会释放未被占用的缓存显存减少退出时清理逻辑出错的概率。另外如果你用了atexit注册清理函数要确保这些函数不会在 CUDA 上下文已经销毁后再去调用 CUDA API。6. 一套可复用的排查链路6.1 从报错堆栈反推异常产生时机面对跑完之后报错第一步永远是读堆栈。但读堆栈有技巧不要只看最上面那行要看最下面那几行那里往往藏着事件循环或框架的收尾调用。比如看到run_until_complete、BaseEventLoop.close、Task.__del__、atexit这些字样基本就能确认是收尾阶段的问题。第二步是给异常加上时间戳。在关键位置打日志记录每个异步任务的开始和结束时间。这样当报错发生时你能对照时间线判断异常是在哪个任务的生命周期里产生的。import asyncio import time async def traced_task(name, coro): start time.time() try: return await coro except Exception as e: print(f[{name}] 异常于 {time.time() - start:.2f}s: {e!r}) raise6.2 用最小复现锁定问题边界跑完之后报错最难的地方是复现不稳定。这时候要做的不是反复跑原程序而是构造最小复现。把可疑的异步调用单独拎出来写一个几十行的脚本看能否稳定复现。能复现问题就锁定在这一小段不能复现说明问题在交互逻辑里需要继续缩小范围。构造最小复现时有几个变量要重点控制事件循环的创建方式、任务的创建和等待方式、异常处理的位置、资源清理的顺序。每改一个变量跑一次记录结果。这个过程虽然笨但比盲目改代码高效得多。6.3 异常兜底与日志补全生产环境里不能指望每个异常都被完美处理但可以做到异常不丢失。给所有创建的任务加上 done callback把异常记录下来import asyncio import logging logger logging.getLogger(__name__) def log_task_exception(task): try: task.result() except asyncio.CancelledError: pass except Exception: logger.exception(后台任务异常) async def main(): task asyncio.create_task(some_work()) task.add_done_callback(log_task_exception) await task对于前端给window.onerror和unhandledrejection加上监听确保异步异常也能被捕获上报window.addEventListener(unhandledrejection, event { console.error(未处理的 Promise 异常:, event.reason); // 上报逻辑 }); window.addEventListener(error, event { console.error(全局异常:, event.error); });6.4 收尾阶段的防御性编程最后分享几条我在实际项目里总结的防御性编程习惯专门针对收尾阶段所有finally块里的清理逻辑都要包 try/except绝不让清理本身抛异常。所有create_task创建的任务都要有异常消费路径要么 await要么加 callback。同步桥接接口要检查当前是否已有运行中的事件循环避免嵌套。CUDA 相关操作集中在主进程数据加载器里只做 CPU 操作。程序退出前显式释放资源不要依赖解释器的自动清理。这些习惯看起来琐碎但每一条都对应着一类真实的跑完之后报错。把它们落实到代码里你会发现那些神出鬼没的收尾异常少了一大半。我在实际使用中发现最有效的单一措施是给所有后台任务加 done callback 并记录异常。这一招几乎能捕获八成以上的跑完之后报错因为绝大多数这类异常本质上都是任务异常从未被获取。剩下的两成靠最小复现和堆栈分析基本也能搞定。 
长河君 · 2026/11/2 9:47:30 · 阅读 1.2k 异步编程收尾阶段异常排查：事件循环、run_sync与CUDA报错解析
1. 为什么错误偏偏挑跑完之后才现身写过异步代码的人大概都经历过这种诡异时刻程序主体逻辑跑得好好的日志一行行刷得飞起结果最后收尾阶段突然甩出一个RuntimeError或者浏览器控制台在页面都快关掉的时候蹦出一句Uncaught TypeError: Cannot read properties of undefined (reading writeText)。更让人抓狂的是这类报错往往复现不稳定有时候跑十次只出现一次有时候换个机器就再也见不到。这个现象背后其实有一个非常统一的解释错误不是跑完之后才产生的而是跑完之后才被暴露出来的。程序在运行期间很多异步任务、事件回调、资源清理动作都处于挂起或排队状态它们的结果没有被立即消费。等到主流程结束、事件循环准备收尾时这些被积压的异常才集中浮出水面。换句话说你看到的报错时间点是异常被结算的时间点而不是它被制造的时间点。理解这一点非常关键因为它直接决定了排查方向。如果你盯着报错那一行代码去找问题大概率会一无所获因为那一行可能只是无辜的收尾代码。真正的病灶藏在更早的某个异步调用、某个未捕获的 Promise、某个没被 await 的任务里。这篇文章会围绕几个高频关键词展开RuntimeError、事件循环、asyncio、run_sync、TypeError以及热搜里出现的runtimeerror: unexpected error from cudagetdevicecount()和 JS 侧的writeText报错。我会把跑完之后才报错这个现象拆成几类典型场景讲清楚每一类的根因、排查链路和修复方案并且给出可以直接抄作业的代码。无论你是写 Python 异步、做前端交互还是碰深度学习框架这套思路都能用得上。2. 事件循环收尾阶段的异常结算机制2.1 事件循环到底在跑完之后做了什么要理解跑完之后报错先得理解事件循环的生命周期。以 Python 的asyncio为例一个典型的事件循环大致经历这么几个阶段创建、运行任务、任务队列清空、取消剩余任务、关闭执行器、关闭循环。很多人只关注运行任务这一段却忽略了后面几个阶段而报错恰恰经常发生在取消剩余任务和关闭这两个阶段。当主协程main()返回后事件循环并不会立刻消失。它会检查是否还有挂起的任务pending tasks。如果有它会尝试取消它们并等待它们响应取消请求。这个取消—响应—清理的过程就是异常集中爆发的窗口。一个任务在被取消时如果它的finally块里有代码抛异常或者它本身吞掉了一个异常没处理这个异常就会在这个阶段被抛出。用一个生活化的类比事件循环像是一个项目经理主流程是白天的正常工作收尾阶段是下班前的清场。白天大家各忙各的有些问题被暂时压着没爆等到清场时项目经理挨个检查那些被压着的问题就一个个冒出来了。所以跑完之后报错本质上是清场阶段的集中审计。2.2 未 await 的协程与孤儿任务最常见的元凶之一是创建了协程却没有 await也没有放进任务队列。看这段代码import asyncio async def fetch_data(): raise RuntimeError(数据源连接失败) async def main(): fetch_data() # 注意这里没有 await print(主流程结束) asyncio.run(main())运行结果会打印主流程结束然后抛出一个RuntimeWarning: coroutine fetch_data was never awaited。注意这里抛的是警告而不是异常因为那个协程压根没被执行异常也就没被触发。但如果换成asyncio.create_taskimport asyncio async def fetch_data(): raise RuntimeError(数据源连接失败) async def main(): asyncio.create_task(fetch_data()) print(主流程结束) asyncio.run(main())这时候fetch_data会被真正调度执行异常会在事件循环收尾时以Task exception was never retrieved的形式冒出来。报错信息里会明确写着任务异常从未被获取这就是典型的跑完之后才报错。提示asyncio.create_task创建的任务如果异常没有被 await 或 add_done_callback 消费异常会被暂存直到任务对象被垃圾回收时才打印。这就是为什么报错时机飘忽不定——它取决于垃圾回收的时机。2.3 取消传播中的二次异常第二类场景是任务取消过程中的异常。当事件循环关闭时它会向所有 pending 任务发送CancelledError。如果某个任务的finally块或except块在处理取消时又抛了新异常这个新异常会覆盖掉取消信号导致收尾阶段报错。import asyncio async def worker(): try: await asyncio.sleep(100) finally: # 清理逻辑本身出错 result 1 / 0 async def main(): task asyncio.create_task(worker()) await asyncio.sleep(0.1) asyncio.run(main())这段代码在main结束后事件循环尝试取消worker触发finally块1/0抛出ZeroDivisionError。最终你会看到一个和CancelledError混在一起的异常堆栈非常难读。排查这类问题的诀窍是在finally块里做清理时一定要用 try/except 包住绝不能让清理逻辑本身抛异常。2.4 执行器线程池的延迟报错还有一类容易被忽略的场景run_in_executor提交到线程池的任务。线程池里的任务如果抛异常异常会被保存在 Future 里只有当你 await 这个 Future 时才会重新抛出。如果你提交了任务却没管它的返回值异常就会一直沉默直到解释器退出或者 Future 被回收。import asyncio def blocking_work(): raise RuntimeError(线程池任务失败) async def main(): loop asyncio.get_running_loop() loop.run_in_executor(None, blocking_work) print(提交完成) asyncio.run(main())这段代码会打印提交完成然后安静地结束异常被彻底吞掉。如果你在main里加一句await asyncio.sleep(1)让 Future 有机会被回收才可能看到异常。这种时有时无的表现正是跑完之后报错最折磨人的地方。3. run_sync 与同步桥接引发的收尾异常3.1 run_sync 的典型使用误区run_sync这类接口不同框架里名字可能不同比如loop.run_until_complete、asyncio.run、某些库提供的run_sync包装本质上是在同步代码里驱动异步逻辑。它的工作模式是创建一个事件循环把协程塞进去跑跑完关闭循环。问题就出在关闭循环这一步。一个非常经典的坑是在已经运行的事件循环里再调用run_sync。比如你在一个 async 函数里想调用一个同步接口而这个同步接口内部又调用了run_sync就会触发RuntimeError: This event loop is already running或者RuntimeError: asyncio.run() cannot be called from a running event loop。import asyncio async def inner(): return 42 def sync_wrapper(): return asyncio.run(inner()) # 危险在事件循环内调用 async def main(): result sync_wrapper() print(result) asyncio.run(main())运行后会直接报RuntimeError: asyncio.run() cannot be called from a running event loop。这个报错看起来是运行中抛的但很多变体会延迟到收尾阶段尤其是当sync_wrapper被放在回调或线程里执行时。3.2 嵌套事件循环的收尾陷阱更隐蔽的情况是嵌套事件循环。有些库为了兼容同步调用会在内部创建新的事件循环。如果外层循环还在运行内层循环关闭时可能会干扰外层的状态导致外层在收尾时报出莫名其妙的RuntimeError。排查这类问题的实用方法是在报错堆栈里找run_until_complete、run_forever、new_event_loop这些关键字。只要看到它们出现在非预期的位置基本就能锁定是嵌套循环问题。修复思路有三条统一异步边界尽量让异步逻辑在同一个事件循环里跑完不要在中间插入同步桥接。用asyncio.to_thread或run_in_executor替代同步桥接把同步调用放到线程里避免创建新循环。如果必须桥接用nest_asyncio之类的补丁仅限开发调试生产环境慎用或者干脆重构调用链。3.3 同步桥接中的资源泄漏run_sync还有一个常见副作用资源没被正确关闭。比如你在run_sync里打开了数据库连接、文件句柄、网络会话但协程因为异常提前退出finally块没执行完循环就关闭了。这些资源会在解释器退出时被强制回收回收过程中可能触发RuntimeError。我踩过的一个真实坑是用某个 HTTP 库的同步接口发请求底层其实是run_sync包装的异步客户端。当请求超时后客户端没被正确关闭等到程序退出时底层连接池的清理逻辑抛出了RuntimeError: Event loop is closed。这个报错出现在程序最后一行日志之后看起来像是跑完之后才发生的实际上是资源清理顺序错了。解决办法是显式管理生命周期。用async with或try/finally确保客户端被关闭并且关闭动作要在事件循环还活着的时候完成。import asyncio import aiohttp async def fetch(url): async with aiohttp.ClientSession() as session: async with session.get(url) as resp: return await resp.text() async def main(): try: data await fetch(https://example.com) print(len(data)) finally: # 确保所有清理动作在循环关闭前完成 await asyncio.sleep(0) asyncio.run(main())4. TypeError 在收尾阶段的几种典型面孔4.1 Cannot read properties of undefined 的时机问题前端热搜里那句Uncaught TypeError: Cannot read properties of undefined (reading writeText)是另一个维度的跑完之后报错。它的典型场景是页面主体渲染完成用户交互也正常但在某个异步回调比如剪贴板操作、定时器、事件监听器里访问了一个已经被销毁或尚未初始化的对象。writeText是剪贴板 API 的方法调用形式是navigator.clipboard.writeText(text)。如果navigator.clipboard在某些环境下是undefined比如非安全上下文、旧浏览器、或者被权限策略禁用就会报这个错。而它之所以跑完之后才出现是因为剪贴板操作通常绑定在按钮点击或异步流程末尾。async function copyToClipboard(text) { // 危险没有检查 clipboard 是否存在 await navigator.clipboard.writeText(text); }正确的写法应该加防御async function copyToClipboard(text) { if (!navigator.clipboard) { // 降级方案 const textarea document.createElement(textarea); textarea.value text; document.body.appendChild(textarea); textarea.select(); document.execCommand(copy); document.body.removeChild(textarea); return; } await navigator.clipboard.writeText(text); }4.2 事件循环里的 this 丢失JS 事件循环里另一个高频TypeError来源是this 绑定丢失。当你把一个对象方法作为回调传给setTimeout或addEventListener时方法里的this不再指向原对象访问this.someProperty就会得到undefined进而读取属性时报TypeError。class ClipboardManager { constructor() { this.text ; } write() { // this 可能不是 ClipboardManager 实例 navigator.clipboard.writeText(this.text); } } const manager new ClipboardManager(); setTimeout(manager.write, 1000); // this 丢失修复方式是用箭头函数或bindsetTimeout(() manager.write(), 1000); // 或者 setTimeout(manager.write.bind(manager), 1000);这类报错的特点是同步调用时正常一旦进入异步回调就崩。因为同步调用时this由调用方式决定而异步回调的调用者是事件循环this就变成了undefined或全局对象。4.3 异步流程中的对象生命周期错配还有一种情况是对象在异步流程中被提前销毁。比如你在组件挂载时发起请求请求返回后更新组件状态但组件在请求返回前已经被卸载。这时候访问组件实例的属性就会报TypeError。React 里经典的Cant perform a state update on an unmounted component就是这个问题的变体。处理原则是在异步回调里访问任何外部对象前先检查它是否还有效。可以用一个标志位也可以用 AbortController 取消未完成的请求。function useData() { const [data, setData] useState(null); useEffect(() { let cancelled false; fetchData().then(result { if (!cancelled) { setData(result); } }); return () { cancelled true; }; }, []); return data; }5. CUDA 初始化报错与跑完之后的关联5.1 cudagetdevicecount 报错的真实含义热搜里那条runtimeerror: unexpected error from cudagetdevicecount(). did you run some c...是深度学习框架里非常典型的报错。cudaGetDeviceCount是 CUDA 运行时 API用来查询可用 GPU 数量。这个报错通常意味着CUDA 运行时初始化失败或者 GPU 在程序运行期间变得不可用。它和跑完之后报错的关联在于很多框架会在程序退出时做设备清理清理过程中会再次调用 CUDA API。如果此时 GPU 已经被其他进程占用、驱动状态异常、或者上下文已经失效清理调用就会失败抛出这个RuntimeError。所以你看到的现象是训练跑完了模型保存了日志也正常结果退出时崩了。5.2 常见触发条件与排查顺序触发这个报错的条件大致有这么几类触发条件典型表现排查方法多进程同时初始化 CUDA子进程报错主进程正常检查 DataLoader 的 num_workers 设置显存不足导致上下文丢失训练中途或退出时报错用 nvidia-smi 观察显存占用驱动与运行时版本不匹配首次调用 CUDA 就报错核对驱动版本和框架要求的 CUDA 版本进程 fork 后复用 CUDA 上下文子进程报错避免在 fork 后直接使用 CUDA程序退出时清理顺序错误跑完后报错检查 atexit 钩子和析构函数排查顺序建议是先确认单进程单卡能否正常跑通再逐步加上多进程、多卡、数据加载器定位到具体是哪一步引入的问题。这个二分法思路在排查 CUDA 问题时特别有效因为 CUDA 报错信息往往很模糊靠猜是猜不出来的。5.3 多进程数据加载的经典坑PyTorch 的DataLoader在num_workers 0时会 fork 子进程。如果子进程里不小心触碰了 CUDA就会触发cudaGetDeviceCount报错。因为 CUDA 上下文不能跨 fork 安全共享。from torch.utils.data import DataLoader # 危险dataset 的 __getitem__ 里用了 CUDA class MyDataset: def __getitem__(self, idx): tensor torch.tensor([1, 2, 3]).cuda() # 子进程里调用 CUDA return tensor loader DataLoader(MyDataset(), num_workers4)修复原则很简单数据加载阶段只做 CPU 操作张量搬到 GPU 的动作放到主进程的训练循环里。class MyDataset: def __getitem__(self, idx): return torch.tensor([1, 2, 3]) # 保持 CPU for batch in loader: batch batch.cuda() # 主进程搬到 GPU # 训练逻辑5.4 退出阶段的清理顺序如果你的报错确实发生在程序退出时可以尝试显式控制清理顺序。比如在训练结束后先手动释放模型和优化器占用的显存再让程序自然退出。import torch import gc # 训练结束后 del model, optimizer gc.collect() torch.cuda.empty_cache()torch.cuda.empty_cache()会释放未被占用的缓存显存减少退出时清理逻辑出错的概率。另外如果你用了atexit注册清理函数要确保这些函数不会在 CUDA 上下文已经销毁后再去调用 CUDA API。6. 一套可复用的排查链路6.1 从报错堆栈反推异常产生时机面对跑完之后报错第一步永远是读堆栈。但读堆栈有技巧不要只看最上面那行要看最下面那几行那里往往藏着事件循环或框架的收尾调用。比如看到run_until_complete、BaseEventLoop.close、Task.__del__、atexit这些字样基本就能确认是收尾阶段的问题。第二步是给异常加上时间戳。在关键位置打日志记录每个异步任务的开始和结束时间。这样当报错发生时你能对照时间线判断异常是在哪个任务的生命周期里产生的。import asyncio import time async def traced_task(name, coro): start time.time() try: return await coro except Exception as e: print(f[{name}] 异常于 {time.time() - start:.2f}s: {e!r}) raise6.2 用最小复现锁定问题边界跑完之后报错最难的地方是复现不稳定。这时候要做的不是反复跑原程序而是构造最小复现。把可疑的异步调用单独拎出来写一个几十行的脚本看能否稳定复现。能复现问题就锁定在这一小段不能复现说明问题在交互逻辑里需要继续缩小范围。构造最小复现时有几个变量要重点控制事件循环的创建方式、任务的创建和等待方式、异常处理的位置、资源清理的顺序。每改一个变量跑一次记录结果。这个过程虽然笨但比盲目改代码高效得多。6.3 异常兜底与日志补全生产环境里不能指望每个异常都被完美处理但可以做到异常不丢失。给所有创建的任务加上 done callback把异常记录下来import asyncio import logging logger logging.getLogger(__name__) def log_task_exception(task): try: task.result() except asyncio.CancelledError: pass except Exception: logger.exception(后台任务异常) async def main(): task asyncio.create_task(some_work()) task.add_done_callback(log_task_exception) await task对于前端给window.onerror和unhandledrejection加上监听确保异步异常也能被捕获上报window.addEventListener(unhandledrejection, event { console.error(未处理的 Promise 异常:, event.reason); // 上报逻辑 }); window.addEventListener(error, event { console.error(全局异常:, event.error); });6.4 收尾阶段的防御性编程最后分享几条我在实际项目里总结的防御性编程习惯专门针对收尾阶段所有finally块里的清理逻辑都要包 try/except绝不让清理本身抛异常。所有create_task创建的任务都要有异常消费路径要么 await要么加 callback。同步桥接接口要检查当前是否已有运行中的事件循环避免嵌套。CUDA 相关操作集中在主进程数据加载器里只做 CPU 操作。程序退出前显式释放资源不要依赖解释器的自动清理。这些习惯看起来琐碎但每一条都对应着一类真实的跑完之后报错。把它们落实到代码里你会发现那些神出鬼没的收尾异常少了一大半。我在实际使用中发现最有效的单一措施是给所有后台任务加 done callback 并记录异常。这一招几乎能捕获八成以上的跑完之后报错因为绝大多数这类异常本质上都是任务异常从未被获取。剩下的两成靠最小复现和堆栈分析基本也能搞定。