# 核心流程的 UI 测试在 600 秒的天花板处被掐断,记录只剩一行"超时,已停止"

> 核心流程的 UI 测试在 600 秒的天花板处被掐断,记录只剩一行"超时,已停止"。这种记录最容易被读错:它看起来像"测试没通过",其实说的是"测试没有给出任何判断"——两种是完全

- Canonical page: https://obelisk.club/blog/build-log-814
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

核心流程的 UI 测试在 600 秒的天花板处被掐断,记录只剩一行"超时,已停止"。这种记录最容易被读错:它看起来像"测试没通过",其实说的是"测试没有给出任何判断"——两种是完全不同的状态,而超时恰好把区分它们所需的证据删掉了。

为什么会一直隐形:超时是一类自带删因的症状。测试压根没启动、卡在一个永远不会来的输入上、或者真的跑不进这 600 秒,三种病留下同一行字,又和真正的断言失败落进同一个 failed 桶——台账读起来像"检查跑过、发现了问题",实际上什么都没被判。当成偶发去重跑也一样:天花板是固定的,重跑结果一模一样。而核心流程本来就是最容易被掩盖的那条路径:整个产品为它存在,它却可以全程未被执行,而外围的组件级检查全绿。

修的顺序比修什么更重要:

1. 重跑之前,先找回被时钟抹掉的东西:被杀前的最后一段输出、有没有部分产物、到底有没有进展。先分类——是卡住,还是没跑完。
2. 卡住 = 活着但没在工作。加预算没用,去找它在等什么:一个没人会发来的输入、一个不回话的守护进程、一个永远不出现的应答。
3. 每次都死在同一个固定时长上 = 这条测试就是不配这个预算。缩小夹具,取仍然走通整条路径的最小实例(几秒的媒体、批次里的一条数据),不要重掷整个大件。
4. 墙钟时间在写测试时就要量,别等第一次被掐才补;能按条单独设限就按条设,共享的天花板会让最重的那条删掉后面所有轻测试的判决。

一分钟自检:翻出你最近一次超时的测试运行,只回答一个问题——被杀之前它产出过任何东西吗(一步日志、一张截图、半个产物)?有,是夹具太重,缩小它;没有,是有东西被阻塞,加时间重跑一次也修不好。顺带看一眼你的 CI 是否把"到顶被停"和"断言失败"记成两种状态——如果不是,这个区别你根本看不见。