Cypress虚拟滚动列表测试本地通过但CI随机失败原因排查

DevOps 小满

2026-10-23

CI环境偶发滚动测试失败的核心原因

环境性能差异带来的竞态错位
本地高性能环境下，元素挂载、虚拟列表渲染、滚动事件派发全链路延迟极低，能刚好匹配测试用例的执行节奏。但CI环境通常是低CPU配置的headless容器，渲染、事件派发的延迟会比本地高一个数量级：当测试代码拿到虚拟列表DOM节点时，可能虚拟列表的初始数据还没渲染完成、内部的滚动监听还没绑定、容器的可滚动高度还没撑开，此时直接执行scrollTo("bottom")，根本不会真正触发触底逻辑——浏览器发现没有可滚动空间，甚至不会派发scroll事件，自然也就不会触发后续的加载请求。
新旧拦截API混用的兼容问题
原代码同时调用了已经废弃的cy.server()和新版的cy.intercept，二者的请求拦截管道存在兼容错位，偶发会导致部分请求没有被纳入监听队列，出现“请求实际发了但测试等不到”的情况。
测试代码的逻辑冗余
原代码中独立写了两次针对虚拟列表的scrollTo("bottom")调用，既没有明确等待第一次滚动的触底状态落地，也没有校验滚动是否真正生效。偶发场景下第一次滚动因为渲染延迟没触发加载，第二次滚动时因为scrollTop已经处于底部位置，浏览器不会再次派发scroll事件，虚拟列表的触底检测逻辑完全收不到事件，自然不会发请求。
缺少滚动完成的显式校验
Cypress的scrollTo命令默认是瞬时执行的，没有等待滚动动画完成、也没有校验最终的滚动位置。CI环境下滚动动作可能还在过渡过程中，代码就已经开始等待接口请求，此时虚拟列表的触底判定还没触发，等待自然就会超时。

修复方案

按照虚拟滚动的实际交互链路重写测试逻辑，每一步都加显式的状态校验，消除环境性能差异带来的节奏错位：

废弃旧的cy.server()调用，统一用cy.intercept做请求监听
注册拦截器后先等待初始列表加载完成，确保虚拟列表已经渲染出足够的可滚动高度
滚动前先校验容器确实存在可滚动空间，避免无意义的空滚动
滚动后显式确认已经到达容器底部，再开始等待新加载请求
去掉冗余的重复滚动操作，避免连续滚动导致的事件丢失

修复后的测试代码：

it("Check if scroll is working on list", { retries: 2 }, () => {
  // 注册接口拦截，覆盖所有列表请求
  cy.intercept('GET','**/api/**').as('listApi')
  // 先等待首次列表加载完成，避免DOM渲染不全就操作
  cy.wait('@listApi', { timeout: 15000 })
  // 校验虚拟列表容器已经具备可滚动空间
  cy.get('[data-cy=VirtualScroll]', { timeout: 15000 }).should(($el) => {
    const el = $el[0]
    expect(el.scrollHeight).to.be.greaterThan(el.clientHeight)
  })
  // 带持续时间的滚动，适配CI环境的低渲染帧率
  cy.get('[data-cy=VirtualScroll]').scrollTo('bottom', { duration: 200 })
  // 显式校验滚动已经真正触底
  cy.get('[data-cy=VirtualScroll]').should(($el) => {
    const el = $el[0]
    expect(el.scrollTop + el.clientHeight).to.be.closeTo(el.scrollHeight, 10)
  })
  // 等待滚动触发的新加载请求
  cy.wait('@listApi', { timeout: 15000 })
  // 断言滚动生效
  cy.get('[data-cy=VirtualScroll]').invoke('scrollTop').should('be.gt', 0)
})

为什么其余监听接口的测试在CI上能稳定通过？因为那些测试都是等接口响应完成、DOM更新渲染完之后才做下一步操作，没有依赖瞬时的事件触发时机。只有这个滚动测试依赖“DOM刚挂载就立刻滚动触发事件”的瞬时节奏，才会被CI的性能差异放大成偶发失败。

内容的提问来源于stack exchange，提问作者Alex T