如果你写过网页自动化大概都经历过这种场景一个航班查询脚本点几下页面最后却花了四五十秒还有一半概率超时。我把整个流程重新梳理之后发现网络和页面加载并不是耗时大户真正卡住的是判断层——什么时候该等、什么时候该点、这次查询到底成没成功。最近我用一个叫 Jev 的判断层重构工具把这块彻底重新写了一遍现在一次航班查询稳稳落在 7 秒左右。这篇文章会从流程拆解、判断层设计、Jev 接入、性能调优到踩坑实录完整复盘整件事适合写爬虫、RPA、自动化测试脚本的朋友参考。1. 先拆解一次航班查询的时间黑洞1.1 完整链路从打开页面到拿到数据时间都花在哪了我最初接到这个需求时脚本已经能跑通但慢到没法接受。每查一次航班要等 40 秒左右运气不好还会因为超时直接抛异常。当时我先做的事不是改代码而是把一次查询的完整链路录下来按步骤拆开计时。典型流程大概是这样的打开 OTA 网站首页输入出发地、到达地、出发日期点击搜索等待搜索结果渲染然后从页面里抽取航班列表最后做一轮“是否真的查到了结果”的确认。这个过程中真正耗时的分布非常有欺骗性。打开页面平均要 2 到 3 秒这还取决于本地网络环境填写表单和点击大概 1 秒到 1.5 秒服务端响应其实不慢从点击搜索到接口返回数据通常只需要 1 到 2 秒但我的脚本为了让数据完整渲染在这里写了一行time.sleep(5)。等 5 秒结束后脚本还要做各种判断页面里有没有“验证”提示有没有出现“航班已售罄”之类的文案结果列表到底渲染出来了没有如果判断条件写得不够聪明就会触发重试重试又会追加 3 到 5 秒的等待。下表是我优化前记录的一组典型耗时可以作为后续对比的基线环节耗时说明打开页面2.5s包含网络请求与首屏渲染填写表单1.2s输入出发地、目的地、日期提交查询0.5s点击搜索按钮强制等待5stime.sleep(5)等待结果出现轮询检查6s每 3 秒检查一次页面最多 2 次数据解析1.5s遍历 DOM 提取航班字段结果确认与保存2s额外做一次断言/快照异常重试10s文案判断错误导致重搜合计约 28~40s视重试次数而定这个表里最扎眼的就是“强制等待”和“异常重试”。它们看起来是两回事但根子上是一个原因判断层太弱。我不清楚结果什么时候出现就只好用固定 sleep 去碰运气我不确定页面文案会不会变就只能用字符串in的方式去猜。猜错了就会走重试分支时间成倍增加。1.2 真正的瓶颈不在动作在“判断”很多人写网页自动化习惯把注意力放在“动作”上怎么写 XPath 定位输入框、怎么点击按钮、怎么滚动页面。这些动作当然重要但它们本身最多花几百毫秒。真正让脚本慢如蜗牛的是动作之后的“判断”环节。我当时的旧代码长得很典型所有判断逻辑散落在主流程里比如使用page_source.find(无航班)来判断搜索结果是否为空使用driver.current_url的变化来判断页面是否跳转使用WebDriverWait等某一个固定元素出现但没考虑元素出现后是不是真的可交互遇到弹窗时先sleep(2)再去找关闭按钮。这些问题凑在一起就会产生连锁反应。举个例子请求结果其实 2 秒就返回了但页面要先弹一个“热门目的地推荐”浮层结果容器被浮层盖住。脚本判断“结果没出现”于是继续等待等到超时又触发一次页面刷新。刷新之后浮层又出现脚本又等……整个过程中服务器早就给数据了浪费的时间全耗在错误的判断和无效重试上。所以说网页自动化其实是可以分成三层的动作层负责执行点击、输入、滚动抓取层负责从 DOM 里提取数据判断层负责回答“现在是什么状态”“下一步该怎么办”。动作层和抓取层往往只占 20% 的耗时判断层却可能占掉 80%因为它不仅决定等待多久还决定要不要重试、要不要改变执行路径。这也让我想到了一个生活化的类比过马路。腿脚利索的人过一条马路也就十几秒但如果红绿灯的判断逻辑有问题一会儿亮绿、一会儿闪黄、一会儿又跳回红灯你在路边反复确认要不要走最后可能花掉好几分钟。机票查询是一样的动作不慢判断很慢。2. Jev 的判断层模型把“判断”从代码里抽出来2.1 判断层为什么值得单独重构在遇到 Jev 之前我也尝试过用更细的WebDriverWait、自己封装断言工具、甚至写一个简单的规则引擎来解决等待问题。但改来改去判断逻辑依然是散落的这个函数里一个if那个函数里一个while项目一复杂就收不住。判断层单独重构的价值在于它能让“对页面状态的理解”成为项目里的一等公民。以前我说“等待结果出现”表达方式是sleep(5)加上一条定位语句重构之后我会把它表达成一个明确的条件单元比如“结果为非空且页面无错误提示”。这个条件单元可以复用、可以打日志、可以统计耗时也可以在不同站点之间移植。还有一个很现实的原因业务方会不断加需求。今天只查航班价格明天要查退改签规则后天要看是否有中转提醒。如果判断逻辑写死在主流程里每加一个新需求就要小心翼翼地改动核心代码。而判断层独立出来后新需求往往只是新增一个判断节点主流程不需要大改。2.2 Jev 的核心抽象判断单元、状态机、条件编排Jev 给我的第一感觉是它把“状态机”当成了组织判断逻辑的主框架。大多数网页自动化脚本不是没有状态而是状态被散落的if隐藏了。Jev 的做法是先把流程抽象成状态机再把每一个状态之间的迁移条件做成“判断单元”。我用 Jev 重构时主要用到三个概念判断单元Condition一个最小粒度的条件对象输入是当前页面上下文输出是布尔值或者置信度。比如“搜索按钮可点击”“结果容器已出现”“页面存在验证弹窗”都是判断单元。状态机StateMachine把页面自动化过程拆成节点和迁移。比如FILL_FORM、SUBMIT、WAIT_RESULT、VALIDATE_RESULT、PARSE_LIST。每个节点只关心自己能不能进入下一个节点。条件编排Orchestrator按照声明式规则把判断单元组合起来支持“事件触发”“短轮询”“语义判断”等不同的等待策略。条件编排可以统一处理超时和重试不需要在每个步骤里单独写循环。这种设计和直接手写if-else最大的区别是判断单元可以被独立地观察和测试。修改一个条件不会影响其他条件条件组合起来也有清晰的语义而不是一堆布尔表达式的堆叠。2.3 为什么选 Jev 而不是手写一堆 if-else很多朋友问我你说得这么玄乎这个 Jev 跟普通的WebDriverWait有什么本质区别我拿实际体验来回答。用传统方式时判断和动作是混在一起的。你点击完之后立刻写几行代码轮询某个元素轮询失败再except一下。这种写法可以解决单个场景但换一个站点、换一种等待条件代码就得重写。而 Jev 判断层抽离后我可以先定义“查询是否完成”这个通用条件然后分别在三个不同站点里复用同一个条件只需要配置对应的元素定位策略和超时时间。另外一个我比较看重的点是可观测性。Jev 会记录每个判断单元的进入时间、退出时间、是否超时、命中了几次甚至能把状态机的整个流转路径输出为日志。之前出问题只能靠猜现在我能直接看到在WAIT_RESULT状态里等了 3.8 秒然后条件result_container_ready命中下一步跳到VALIDATE_RESULT。这种数据对排查慢查询太有帮助了。另外Jev 支持本地部署的轻量模型做语义判断。有些页面文案不稳定比如“很抱歉当前没有符合条件的航班”和“暂未查询到相关航班”字符串精确匹配很难覆盖全部。用本地模型做语义分类可以统一判断成“空结果”。这样就不需要维护一大串正则和关键词也更不容易被页面改版击穿。3. 用 Jev 重构航班查询判断层实操全记录3.1 重构前脚本的现状与问题清单在动手重构之前我先把旧脚本的问题整理成了一份清单每条都标了预计的时间收益。固定time.sleep(5)强制等待结果改成页面出现结果容器后才继续预计省 3 秒以上。用字符串匹配判断空结果改成本地语义模型判断减少误判导致的重试预计省 5 到 10 秒。所有逻辑写在一个大函数里拆成状态机方便定位卡点不直接省时间但能省排查时间。没有全局超时一旦页面卡住会死等加上全局超时后异常能快速退出预计避免无限等待。每次查询都重新启动浏览器改成复用浏览器实例预计省 1.5 秒到 2 秒。这份清单的价值不在于每条都准确而在于让我明确了重构范围不要为了炫技去改抓取逻辑重点只改判断层。这也是 Jev 重构的核心思路——保持动作层和抓取层不变只替换“怎么判断状态、怎么等待、怎么处理异常”。3.2 画出查询流程状态机重构判断层的第一步不是写代码而是画状态机。我建议每个人都先做这一步。拿一张纸把一次航班查询从开始到结束的所有可能状态列出来再把状态之间的迁移条件写清楚。我当时的航班查询状态机大概是这样的INIT → FILL_FORM → SUBMIT → WAIT_RESULT → VALIDATE_RESULT → PARSE_LIST → DONE → RETRY迁移条件分别是INIT → FILL_FORM页面加载完成出发地输入框可交互。FILL_FORM → SUBMIT出发地、到达地、日期都已填好搜索按钮可点击。SUBMIT → WAIT_RESULT点击搜索后URL 发生变化或者页面上出现 loading 状态。WAIT_RESULT → VALIDATE_RESULT结果容器出现或超时达到 3 秒。VALIDATE_RESULT → PARSE_LIST结果列表不为空且页面没有错误弹窗。VALIDATE_RESULT → RETRY结果为空或页面出现异常提示。PARSE_LIST → DONE航班数据抽取完成并写入结果文件。画完状态机后我发现旧脚本最大的问题是没有RETRY状态的退出条件。原来的代码如果判断失败会重新搜索但重新搜索后还是用同样的判断逻辑于是很可能无限循环。状态机加上了RETRY之后我给它配置了最大重试次数 1 次超过就直接进FAILED状态退出彻底避免死循环。3.3 用 Jev 声明式规则替换硬编码判断有了状态机下一步就是把每个迁移条件实现成 Jev 判断单元。这里我给你看一段简化后的思路实际 API 以你用的版本为准但核心结构是这样的from jev import StateMachine, Condition, toggle class ResultContainerReady(Condition): def check(self, ctx): container ctx.driver.find_elements(css selector, .flight-item) return len(container) 0 class EmptyResultDetected(Condition): def check(self, ctx): # 使用本地语义模型判断页面是否为空结果 text ctx.get_visible_text(.result-panel) return ctx.text_classifier.predict(text) empty然后把这些判断单元挂到状态机的迁移上machine StateMachine( states[ INIT, FILL_FORM, SUBMIT, WAIT_RESULT, VALIDATE_RESULT, PARSE_LIST, DONE, FAILED ], transitions[ {from: INIT, to: FILL_FORM, conditions: [FormReady()]}, {from: FILL_FORM, to: SUBMIT, conditions: [SearchClickable()]}, {from: SUBMIT, to: WAIT_RESULT, conditions: [LoadingAppeared()]}, {from: WAIT_RESULT, to: VALIDATE_RESULT, conditions: [ResultContainerReady()], timeout: 3}, {from: VALIDATE_RESULT, to: PARSE_LIST, conditions: [NotEmpty()]}, {from: VALIDATE_RESULT, to: RETRY, conditions: [EmptyResultDetected()]}, ] )每个判断单元都是一个小类check方法只负责返回“当前条件是否成立”。它不关心上层怎么用也不直接操作业务流程。这样我可以为每个单元写独立的单元测试也可以在做一次查询时把每个条件的命中耗时打出来。用这种方式重构之后代码里基本看不到time.sleep了。等待这件事被 Jev 的条件编排接管条件不满足时Jev 会按默认间隔我通常设 200ms重新检查直到满足或超时。这样既不会多等也不会因为等得太短而误判。3.4 让 Jev 接入本地语义判断在航班查询场景里最坑我的其实是空结果判断和弹窗识别。不同的 OTA 网站提示文案五花八门“很抱歉暂时没有找到符合条件的航班”“当前城市暂不支持查询”“系统繁忙请稍后重试”用字符串精确匹配要么漏掉要么误伤。我当时临时写过一个关键词集合把“抱歉”“暂无”“不支持”“繁忙”都放进去结果还是出问题因为有些页面的失败提示是图片根本爬不到文字。Jev 的本地语义判断解决了这个痛点。它是在本地跑的一个轻量级文本分类模型不需要把页面内容发到第三方服务也不需要在本地配置 GPUCPU 就能跑。它接收一小段文本返回一个标签比如empty_result、error_page、normal_result。我在判断结果时不再问“页面里有没有某些关键词”而是问“这个页面的整体语义是空结果还是正常结果”。实际操作上我只取页面里结果区域的可见文本送去判断不会傻乎乎地把整张页面的脚本、样式、广告全丢给模型。这样推理速度很快一次判断不到 50ms。如果把整页文本传过去不仅慢而且会把广告文案混进来导致语义被污染。接入方式也很简单我在判断单元里加了一行class EmptyResultDetected(Condition): def check(self, ctx): text ctx.get_visible_text(.result-panel) return ctx.text_classifier.predict(text) empty本地模型在初始化时加载一次之后所有查询实例复用。判断单元本身是无状态的只依赖传入的ctx所以多线程场景下也不会互相干扰。3.5 压到 7 秒参数调优和取舍状态机跑通后速度已经比原来快了大概能压到 10 秒到 12 秒。但距离“7 秒跑完一次查询”还有一段距离这时候需要做参数级调优。第一把轮询间隔从 500ms 降到 200ms。Jev 的条件编排默认对每个条件做线性轮询过去为了减少资源占用我设了 500ms 一次。但本地判断非常轻量200ms 和 500ms 对 CPU 的影响几乎可以忽略却能明显缩短“条件已经满足但还没被检查到”的空窗期。第二给重点条件设置合理的超时。比如WAIT_RESULT状态我一开始设 5 秒超时但实际数据表明 99% 的正常查询在 2 秒内就能出现结果容器。把超时改成 3 秒后异常场景能更快暴露出来正常场景完全不受影响。第三复用浏览器实例。旧脚本每次查询都启动一个新 Chrome光启动就要 1.5 秒以上。重构后我把浏览器实例常驻查询时只需要新开一个标签页或者清空页面状态后复用当前页面。这个改动直接省下 1 到 2 秒。第四避免等待整页加载。很多 Selenium 代码习惯用document.readyState complete来判断页面加载结束但航班搜索结果往往是异步加载的页面 DOM 早就 complete 了接口数据才刚回来。所以我不再等待整页加载而是只等待结果容器出现。第五精简重试策略。把重试次数限制为 1 次而且只有在VALIDATE_RESULT判断为空结果时才重试。如果是因为超时进入FAILED直接退出并记录错误不重试。这样既不会因为网络抖动丢数据也不会出现重试风暴。调优完成后效果很直观环节优化后耗时打开页面/复用标签1.0s填写表单1.0s提交查询0.4s结果等待事件短轮询2.2s结果校验语义判断0.4s数据解析与保存1.5s收尾与日志0.5s合计约 7.0s这个 7 秒不是靠把某个 sleep 删掉换来的而是靠把整个判断层换成“状态机 条件编排 本地语义模型”之后从多个环节里一点一点挤出来的。4. 常见问题与排查技巧实录4.1 判断超时和重试策略怎么配重构之后我遇到的第一个坑是超时时间设置不合理。当时我把WAIT_RESULT的超时设成 2 秒结果发现部分机场查询在高峰期会超过 2 秒才返回数据导致脚本频繁进入重试。重试之后又因为页面状态没有完全重置造成二次误判。后来我总结了三个经验值正常响应在 1 秒到 2 秒之间的场景超时设 3 秒轮询间隔 200ms正常响应可能到 5 秒的场景超时设 6 到 8 秒同时配合一个较短的“前置条件”快速失败重试次数最多 1 到 2 次超过 2 次往往是判断条件本身有问题而不是网络问题。重试策略的核心不是“多试几次”而是“用不同的条件再试一次”。如果第一次是从WAIT_RESULT超时进入FAILED第二次查询应该先检查页面是否被弹窗遮挡而不是简单刷新重搜。这一点可以用状态机的RETRY节点携带不同的判断条件来实现。4.2 状态机卡死和脏状态清理Jev 重构初期我的状态机偶尔会卡死在某个状态。查了几天发现是页面残留状态导致的。比如第一次查询失败后页面弹了一个“温馨提示”的浮层第二次查询进入FILL_FORM状态时出发地输入框被浮层挡住脚本判断“表单可填写”的条件一直不成立于是在FILL_FORM状态里空转到超时。Jev 里对应的解决方案是给状态迁移加“清理钩子”。进入INIT状态时强制关闭所有可能的弹窗、重置表单内容、回到页面顶部。这个清理操作可以写成判断层的独立单元叫做ResetPageState作为INIT的进入条件之一。它不负责业务判断只负责把页面环境恢复到干净状态。另外一个土办法是把状态机的日志打开卡死的时候直接看日志里最后进入的状态是哪个再根据这个状态反查页面残留因素。不要一上来就加sleep那样只是掩盖症状。4.3 多页面并发下的判断隔离我后来把业务从单次查询扩展到了批量查询需要同时跑多个航班查询任务。这时候发现 Jev 的判断单元虽然是独立的但状态机实例如果共享全局变量会出现严重的状态污染。比如两个任务同时判断“结果容器是否出现”一个任务查的是上海到北京另一个查的是广州到深圳。如果它们通过同一个全局的driver查找元素判断结果会互相干扰。解决办法很简单每个任务创建独立的StateMachine实例判断单元只接收当前任务对应的ctx不引用任何全局 driver。举一个配置层面的例子def run_query(ctx): machine StateMachine.build_from_config(FLIGHT_QUERY_CONFIG) result machine.run(ctx) return result这样每次查询都持有自己的上下文状态机的内部状态不会泄露到其他任务里。并发测试下来20 个任务同时跑也没有出现互相踩踏的问题。4.4 判断层的日志和可观测性最后想重点说日志。我踩过最大的坑是没有日志出问题只能靠猜。Jev 重构后我给每个判断单元加了进入和退出记录每次条件命中都会打印[WAIT_RESULT] checkResultContainerReady hitTrue elapsed0.31s [VALIDATE_RESULT] checkNotEmpty hitTrue elapsed0.04s这些日志看起来不起眼但在排查问题时价值极高。它能直接回答三个问题当前卡在哪个状态等待了多久命中条件是什么我还习惯把每个状态节点停留时间汇总到一张表里每隔一段时间看一眼就能发现哪个节点的时常波动大是不是又遇到了页面改版或者反爬策略调整。这比等用户报故障再回头查日志高效得多。状态节点平均耗时超时次数备注FILL_FORM1.0s2输入框被浮层遮挡WAIT_RESULT2.2s1高峰期网络延迟VALIDATE_RESULT0.4s0语义判断稳定PARSE_LIST1.5s0数据量增加会变慢有了这种数据后续优化就不用再拍脑袋。每次改完判断条件跑一轮回归看节点耗时变化就能快速确认改动是否有效。这次重构最值钱的不是那 30 秒而是我终于能看清楚每次查询到底卡在哪一步了。后面加低价提醒、航变监测只是往状态机里加两个节点的事。最后分享一个小技巧重构判断层之前先把手动流程跑十遍把每一步的截图和时间点记下来再动代码。没有这份真实数据你都不知道该把力气花在哪个环节上。