你可能会说：
- “明明修好了一个问题，怎么另一个好好的地方又坏了？”
- “以前能用的功能，这次更新之后不能用了。”
它是什么
回归最麻烦的地方在于没人盯着：大家的注意力都在这次改的地方，原本好好的地方默认"没动过"，也就没人去看。
防回归靠的是固定的检查：每次改动之后，把关键页面、关键功能都过一遍，最好是自动的，比如测试、构建产物比对、截图比对。
要小心"检查通过"的错觉：测试只覆盖它写到的地方。测试全绿的同时，没写到的地方照样可能坏了。
打个比方
像修水管时碰松了隔壁的接头：你修好的那处不漏了，楼下却开始滴水。
在这个网站里
兄弟项目 E2E Review 的一次重构里，删样式删掉了配图依赖的颜色变量，示意图全变成黑块，术语图解也没了样式；可当时 7 项测试全部通过，状态报告还写着"视觉检查 通过"（第 15 课）。
容易搞混的地方
常见误解
测试都通过了，就没有回归
正确理解
测试只能证明它覆盖到的地方没坏。视觉、配置、跨文件的依赖，常常不在任何测试里。
你可以这样告诉 AI
复制下面这段，贴给你的 AI
这次改动可能影响到哪些原本正常的页面和功能？列出来，逐项给出验证办法；再告诉我现有测试覆盖了其中哪些、没覆盖哪些。
接下来去哪
先知道
- 重构——在不改变外在表现的前提下，调整代码的结构：抽出公共部分、换个组织方式、删掉用不到的东西。
接着看
- 截图比对——把改动前后的页面截图，逐像素比较差了多少。人眼看不出的细微变化，它都能数出来。
在这些课里出现
相关的真实事故