UI 快照测试与视觉回归：让"改 A 坏 B"无处可藏

做前端最烦的不是新功能写不出来，是改了一个组件，另一个页面的角落默默变形了。视觉回归测试是解决这个问题的唯一办法，我把落地过程写下来。 原理很简单：把组件的渲染结果存成图片基准，每次改动后重新渲染并逐像素比对，差异超过阈值就报失败。难点全在工程细节上。 细节一：渲染环境必须稳定。字体、浏览器版本、屏幕缩放、甚至抗锯齿设置，任一不一致都会导致大量假阳性。推荐固定版本的无头浏览器跑在容器里，字体用固定版本随镜像打包。这是最容易踩的坑，环境不稳的话，一周之内团队就会因为误报而放弃这套机制。 细节二：阈值和遮罩。抗锯齿、渐变、阴影这些区域天然会有细微差异，需要设置合理的像素差异阈值，并对动态区域（时间戳、随机数、用户头像）加遮罩忽略。 细节三：基准图的更新流程要显式。差异出现时，人要看一眼判断是预期变更还是回归，确认后更新基准。这一步必须人工，自动更新等于没有测试。 细节四：只测关键路径。不要给所有组件所有状态都做快照，维护成本会爆炸。优先覆盖被多处复用的基础组件，以及历史上有过视觉问题的组件。 关于 agent 的配合：让 Claude Code 写这套流水线和 CI 集成，它能把无头浏览器启动、图像比对、报告输出串成一条完整的脚本。让 MiMo Desktop 做人工审核环节——把所有差异图铺在一个页面对比，一眼扫过去判断哪些是预期变更，比在 CI 日志里一张张点开快得多。 最后一句：视觉回归测试的价值不在首次搭建，在长期坚持。它的收益是复利型的，前提是别让它因为误报太多而被关掉。