很多前端开发者在用Cypress做测试的时候，都碰到过这么个事儿：改了业务组件里的代码，或者改了测试脚本，本来想看看结果，却还要手动去Cypress的Test Runner里点“Run All”，或是找到对应测试文件点那个灰色的播放按钮，来回折腾好几遍，效率特别低。这时候就会想到Cypress的实时重载功能——要是它能自动触发测试就好了，可惜不少人折腾半天也没弄明白为啥不生效，今天咱们就把这事说透。
一、先搞明白，我们说的Cypress实时重载到底是什么
1.1 不是浏览器自动刷新，是测试自动重跑
很多人刚接触的时候会混淆，以为实时重载是像Vite那样刷新整个浏览器页面，其实不是。Cypress的实时重载，指的是当你修改了测试文件本身，或是修改了被测试的业务代码，或是调整了Cypress自己的配置文件时，Cypress会自动重新执行对应的测试，不需要你手动操作。这么一说是不是就懂了？就是把“触发测试”这个动作，从手动改成自动，省掉你点按钮的功夫。
1.2 平时用它能帮我们省多少功夫？
举个例子：你正在做一个登录组件，改了“密码输入时显示明文”的逻辑，这时候只要保存代码，要是开了Cypress的实时重载，所有和登录相关的测试都会自动跑一遍，不用你再去打开Cypress，找对应的测试文件，点播放。要是你有几十个测试，这么来回折腾一次至少要30秒，一天折腾个十次，就能省出几分钟，积少成多就是效率的提升。
二、实时重载的触发条件，哪些情况能自动生效
2.1 核心触发的两类文件
Cypress的实时重载，本质是监听两类文件的修改： 第一类是测试文件，也就是你放在cypress/e2e或者cypress/component文件夹里的那些.cy.js文件，只要改了这里的内容，Cypress立马会触发重载； 第二类是业务代码文件，注意：这里只有在Cypress的组件测试模式下才生效——如果你是用E2E模式（跑整个页面的测试），改业务代码的话，只有你的前端Dev Server（比如Vite、Webpack）自动刷新了页面，Cypress才会跟着重载测试；要是用组件测试，Cypress会直接监听你指定的业务文件夹，改了就触发测试。
2.2 容易忽略的小触发点：配置文件
如果你改了Cypress的配置文件（cypress.config.js或者原来的cypress.json），有时候也会触发重载，但有时候不会——这时候得看你是怎么打开Cypress的：要是用npx cypress open打开的Test Runner，一般会触发；要是用npx cypress run（无头模式），就不会。
三、开发环境最常踩的适配坑，以及怎么解决
3.1 坑1：改了业务代码，测试没自动重载
这是最多人踩的坑，比如改了src下的组件代码，Cypress里的测试根本没动，还是旧的结果。
3.1.1 问题原因
Cypress默认只会监听测试文件，不会监听你的业务代码，除非你手动在配置里关联业务代码的路径，告诉它“只要改了这些文件，就重载测试”。
3.1.2 解决方法：修改Cypress配置文件
这里用的技术栈是JavaScript+Cypress组件测试，配置的时候要把业务代码的监听路径加上，示例如下：
// cypress.config.js，关键是component.devServer部分的配置
const { defineConfig } = require('cypress');
const { devServer } = require('@cypress/vite-dev-server'); // 用Vite的Dev Server，和你的前端匹配
module.exports = defineConfig({
// E2E模式的配置，一般不用改，确保和前端Dev Server的端口一致
e2e: {
baseUrl: 'http://localhost:5173', // 这里要和你本地Vite启动的端口一样，比如Vite默认是5173
},
// 组件测试模式的配置，核心就在这里
component: {
devServer, // 指定用Cypress的Vite Dev Server，适合Vanilla JS或React项目
specPattern: 'cypress/component/**/*.cy.js', // 测试文件的位置，改这里的话要对应你的文件
supportFile: 'cypress/support/component.js', // 支持文件的位置，一般不用动
devServerConfig: {
vite: {
// 重点：监听src目录下所有js、jsx文件，改了就触发重载
build: {
watch: {
include: 'src/**/*.{js,jsx}', // 要是你的业务代码在其他文件夹，比如src/components，就改成src/components/**/*
},
},
},
},
},
});
配置完之后，只要业务代码里的js文件改了，Cypress就会自动重载测试，是不是很简单？
3.2 坑2：改测试文件，重载了但没跑新代码
有时候你改了测试文件里的逻辑，比如新增了一个断言，结果重载之后还是老的测试结果，没跑新代码。
3.2.1 问题原因
Cypress的文件缓存搞的鬼，它会把已经加载的测试文件存在缓存里，不会重新加载新的修改后的文件。
3.2.2 解决方法
有两个简单的方法：一是在打开Cypress的时候加参数，清缓存，比如用npx cypress open --no-spec-cache；二是直接删掉Cypress的缓存文件夹，一般是项目根目录下的.cypress文件夹，删掉再重启Cypress，就能解决。
3.3 坑3：切换开发分支，重载后还是旧代码
你换了一个分支，改了测试或者业务代码，结果Cypress里的测试还是旧分支的结果，这时候大概率是文件监听延迟或者系统的问题。
3.3.1 问题原因
有些系统（比如WSL、远程开发环境）的文件监听机制有延迟，或者太懒，不会主动去检查文件的修改，导致Cypress还是拿旧的内容。
3.3.2 解决方法
改Cypress的Dev Server配置，用轮询的方式监听文件，不管文件有没有修改，定期检查：
// 把之前的watch配置改成这样，加上usePolling: true
devServerConfig: {
vite: {
build: {
watch: {
usePolling: true, // 开启轮询监听，适合有文件监听延迟的系统
interval: 1000, // 每隔1秒检查一次，1000毫秒，可调整
include: 'src/**/*.{js,jsx}',
},
},
},
},
这样即使系统监听不及时，Cypress也会定期检查文件修改，触发重载。
四、这些细节得注意，不然白折腾
4.1 必须用dev模式打开Cypress
只有用npx cypress open打开Test Runner的时候，实时重载才会生效，要是用npx cypress run（无头模式，适合CI），是没有交互的，也不会有实时重载，这个别搞混。
4.2 业务代码的路径要写对
刚才配置里的include路径，必须和你实际放业务代码的文件夹完全一致，比如你把组件放在src/components里，就不能写src/**/*，不然Cypress找不到，不会监听，这是很多新手容易犯的错。
4.3 偶尔出问题就手动重置
要是怎么弄都不重载，别死磕配置，直接关掉Cypress，删掉.cypress缓存文件夹，重新打开，一般都能解决，很多时候是缓存或者监听的小问题，不是大配置错了。
五、总结
5.1 实时重载的核心价值
它最大的好处就是让测试的反馈速度变快，不用频繁手动触发，对于开发阶段的调试特别有用，尤其是测试用例多的时候，能节省大量时间。
5.2 适配问题的解决思路
碰到适配问题，先从触发条件入手：是不是配置里没关联业务代码？是不是用错了Cypress的模式？是不是缓存的问题？一步步排查，基本都能解决，不用怕折腾。
评论
围绕“Cypress实时重载功能的触发条件与开发环境适配问题解决”参与讨论