Chromatic 这类视觉测试工具的账单最容易被忽略的一点是它不是按项目个数收费而是按“快照消耗量”收费。你的代码库可能只有几十个组件但每个组件在不同浏览器、不同视口下都生成快照再加上每次提交都跑一遍云端全量月底的快照数就会非常难看。这篇文章我来讲一套从“全量快照”改成“有效快照”的优化思路。做法不绑定 Chromatic 特有接口Percy、Argos、Applitools 这类工具同样能套用。如果你的项目属于多组件、多浏览器、多视口、PR 频繁的类型把快照消耗降到原来的十分之一并不夸张。很多人觉得视觉测试省钱就是把并发调低、少开几个 CI 任务实际上账单大头通常来自测试覆盖范围本身。同样一段代码多配一种浏览器就是多一倍快照多配一个视口又可能多一倍快照每个 PR 都全量跑一次整体消耗还会按提交次数继续放大。与其到最后去处理账单异常不如先从快照生成逻辑上把不必要的内容按掉。下面我按实际落地顺序拆一遍先判断问题在哪再动手改配置最后做长期约束。1. 先搞清楚视觉测试账单是被什么撑大的1.1 计费逻辑不是按项目数而是按“快照消耗量”Chromatic 和同类视觉测试平台通常不是只按项目数量或成员数量收费真正决定费用增长的是每次测试产生的快照数量。这里的快照可以简单理解成“一张被上传到云端做对比的截图”。一个组件 Story 只要进入测试集就可能对应一张或多张快照如果配置了多个浏览器、多个视口快照数量还会成倍增加。我经常看到这样的项目功能代码不算复杂但 Storybook 里每个组件都写了七八个 Story每个 Story 又配了桌面端、平板端、手机端三种视口云平台那边再开 Chrome、Firefox、Safari 三种浏览器。这样算下来一个组件可能产生几十张快照。组件库只要达到几十个组件一次云测试就是上千张快照。这个量级在免费额度里可能看不出问题一旦团队进入正常开发节奏每次 PR 都触发一次全量测试账单增长会非常直接。还要注意“重复跑”的问题。很多平台不仅会捕获正常结果重试、超时后的再次抓取也可能被计入快照使用量。批量告警、CI 网络抖动、资源不足导致的截图失败都会让同一份代码被反复上传比较。这类消耗和代码覆盖没有关系纯粹是流程问题但它对账单的影响可能比想象中大。所以第一步不是急着删 Story而是先搞清楚你当前一个 build 到底生成了多少快照以及这些快照分别来自哪里。1.2 默认配置会放大消耗的几个位置大多数视觉测试工具接入 Storybook 之后默认行为都是“尽量多测”。这符合工具本身的目标但不一定符合账单目标。以下位置特别容易放大消耗。第一Story 全量进入测试集。只要 Storybook 能识别到的 Story默认都会被云平台抓取。哪怕只是一个验证交互逻辑的辅助 Story也会被当成视觉回归用例处理。第二视口配置被复制到所有 Story。很多团队在 Storybook 全局配置里设置了多个 viewport例如 iPhone SE、iPhone 14、iPad、桌面 1280、桌面 1920。全局视口一多每个 Story 都会按这些尺寸各生成一张快照。实际业务里并不是每个组件都需要在五种尺寸下检查。第三浏览器矩阵过宽。Chromatic 这类工具可以配置 Chrome、Firefox、Safari、Edge 等浏览器。浏览器越多快照倍数越高。很多组件并不涉及浏览器差异却为每个浏览器付了一遍快照成本。第四每次提交都触发全量回归。如果 CI 里只要 push 就运行云端视觉测试那么一个分支每天的提交次数会直接把快照消耗拉到很高。团队在功能分支上反复调试样式时每调整一次都会跑一整轮全量快照其中大部分组件完全没有变化。第五交互状态也被当成快照点。一些工具支持在 Story 的 play 函数里模拟点击、悬浮、输入操作操作后的状态也会被捕获。这类测试很有价值但成本也高。一个 Story 里有三次交互就相当于三个或更多测试点。如果这些交互状态并不是你需要长期守护的核心样式就不该每次都在云端跑。把这几类因素放在一起就能看出账单高的原因通常不是“测试太多”而是“无效快照太多”。2. 动手前先盘点当前项目建立减少快照的基线2.1 先找出所有快照入口不要凭感觉判断哪些组件消耗多。先拉取一份实际快照清单或者根据 Storybook 的索引文件做一个估算。最简单的做法是先在本地跑一次 Storybook 的静态构建然后找到生成的index.json或stories.json文件。这类文件会列出所有 Story 的 title、id、importPath 等信息。用一个临时脚本按 title 分组统计就能知道每个组件下面有多少个 Story。路径以你项目实际输出为准不同 Storybook 版本文件名可能不同。下面是一个通用的统计参考脚本不是固定命令需要根据你的构建产物结构调整# 示例脚本统计 Storybook 索引文件里的 Story 数量 node -e const data require(./storybook-static/index.json); const map {}; for (const [id, item] of Object.entries(data.entries || {})) { const comp item.title || unknown; map[comp] (map[comp] || 0) 1; } console.table(map); 如果你用的平台提供了快照报告也可以直接打开最近一次云测试结果按组件或 Story 维度看快照数量。有些平台还支持导出 CSV这种数据比本地估算更准确。这一步的核心目的是形成一份“快照消耗基线”。不要边改边看效果因为缺少基线的话你不知道改动后到底省了多少也不知道是否有组件因为误删而完全失去视觉守护。基线里至少要记录三组数据当前 Story 总数、当前浏览器数量、当前视口数量以及最近一次全量测试的快照总量。2.2 按组件变更频率给测试分级拿到 Story 清单后不要直接开始删先把组件按价值和变更频率分级。我一般会分成三档。高优先级公共组件、设计系统核心组件、用户主流程里最容易出现样式回归的组件。比如 Button、Input、Table、Modal、Navbar。这类组件要保留足够的视觉覆盖浏览器和视口可以适当保留两到三个关键组合。中优先级业务页面、业务组件只对用户可见的关键状态做视觉测试。比如页面加载态、空态、错误态、主要数据态。不需要把所有数据组合都变成 Story。低优先级很少变动的静态页面、营销页面、纯文档类组件、长期无人维护的旧页面。这些可以在合并到主干时跑一次而不是每个 PR 都跑。做完分级后重新看一遍“快照消耗基线”。你会发现真正值得每次 PR 都跑全量快照的组件可能只占整个项目的一半甚至更少。其余部分应该靠版本发布前的全量回归来覆盖。这个分级表可以直接写在 README 或项目文档里后续新 Story 进来时按同一套标准评审。否则今天省下来的额度过两个星期又会因为随手新增 Story 涨回去。3. 用配置和代码按层级削减快照数量3.1 从 Story 层过滤低价值用例Story 是视觉测试的最小入口。控制 Story 数量是最直接的削减方式。但不是让所有 Story 都消失而是把“不必要的 Story”和“有必要的 Story”区分开。如果你发现某个组件下面有二十多个 Story大部分只是参数组合不同就应该考虑合并。一个视觉状态只需要保留一个最有代表性的 Story。比如 Badge 组件用“默认”“成功”“警告”“危险”四个状态就能覆盖主要样式不必再为每个状态多写一个“带图标”的 Story。带图标的变体可以在其中一个代表性 Story 里用参数组合展示不必为每一种图标单独建 Story。另一个容易被忽略的点是有些 Story 存在的目的只是为了验证组件可交互并不关心它的最终截图效果。这类 Story 可以不打入视觉测试集。很多视觉测试平台支持在 Story 或者组件级别做跳过标记不同版本和平台叫法不同常见的是 skip、disable、exclude 这类配置。具体字段以你当前使用的工具文档为准但判断标准是一样的如果一个 Story 的截图变化不会帮助你发现回归就不需要让它进入云端对比。我一般会在内部定一个规则新建 Story 时先问自己一个问题——“如果这个 Story 的截图发生了样式变化我会不会认真来看”如果答案是不会就说明这个 Story 不适合放进去。3.2 用视口、浏览器和交互参数做减法很多项目的视觉测试成本高不是因为 Story 多而是因为每个 Story 都在多浏览器、多视口下重复截图。这部分的优化收益最大也最容易操作。先看视口。对大多数组件来说常见的检查尺寸可以收敛为两种移动端 390 或 414桌面端 1280 或 1440。平板端通常只在抽屉、弹窗、栅格布局这类确实会改变排列方式的组件上检查。不要把五个视口全部挂到全局最好改成一个基础视口列表再让个别组件单独补充需要的尺寸。再看浏览器。视觉回归测试最核心的价值是防止“代码改动导致布局或样式变化”并不一定要在所有浏览器里都重复验证。如果项目使用现代 CSS 标准并且主要用户集中在 Chrome 内核浏览器可以先把浏览器配置收敛为默认浏览器最多保留一个移动端浏览器。真正需要跨浏览器验证的情况比如针对 Safari 的兼容补丁、针对 Firefox 的细节差异再单独给相关组件开一个浏览器矩阵。这样既保留跨浏览器能力又不会让每个普通 Story 都承担两到三倍快照。交互参数也要控制。一个 Story 里的交互状态越少快照点就越少。如果有某个组件需要验证“点击后展示弹窗”“输入后展示错误信息”“悬浮后显示 tooltip”建议拆成多个独立 Story而不是一个 Story 里连续做三次操作。拆开之后你还能更清楚地定位到底是哪个交互状态出了问题。但同时也要注意拆成多个 Story 不等于每个都必须进视觉测试。确定这几个状态里哪个才是视觉回归的高风险点只保留那一个或两个。3.3 用批处理和任务拆分管理高峰消耗除了测试维度触发频率也需要控制。默认情况下很多项目是“每次 push 都全量跑”。如果是个人项目还好如果是团队项目一个功能分支可能同时有十几个人在提交每天触发几十次全量测试。这个数字比视觉测试自身的配置还要可怕。先做触发条件收敛。常见思路是只在目标分支和特定 Pull Request 事件上运行视觉测试开发分支的中间提交不跑。比如main分支每次合并前跑一次全量PR 阶段按变更范围跑一次增量。如果属于文档、依赖升级、纯配置调整可以直接跳过。再按文件变更范围决定运行级别。只要 CI 能拿到当前分支相对基准分支的变更文件列表就可以根据路径判断是否需要触发视觉测试以及需要跑哪些组件。下面是一段通用伪代码# 示例按变更目录决定是否运行视觉测试 CHANGED$(git diff --name-only $BASE...$HEAD) if echo $CHANGED | grep -qE ^docs/|\.md$; then echo skip_visual elif echo $CHANGED | grep -qE ^src/components/; then echo run_visual_for_components else echo run_visual_default fi这段脚本的核心不是具体命令而是建立“开关机制”。拿到结果后CI 再决定调用哪一个视觉测试命令是跑全量还是按指定目录过滤。如果你的项目是 monorepo最好把视觉测试任务拆到包或应用维度。避免任何一个仓库的任意改动都触发整个 monorepo 的视觉测试。拆分后每个视觉测试任务的范围更小快照数量更可控失败时也更容易定位。4. 引入本地验证和差分思维让 CI 只在必要时消费云端额度4.1 本地先跑静态检查和组件自测云端视觉测试的价值在于有历史基线能自动对比前后差异。但很多样式问题其实不需要云端对比也能发现。本地 Storybook 本身就是很有效的检查工具。我的经验是在提交代码前先本地启动 Storybook快速人工扫一遍改动组件的几个核心状态。确认布局没有因为重构发生明显偏移颜色、间距、字体层级没有明显异常再进入 CI。这一步不消耗云端额度也不需要写额外测试但因为工程师每天会接触组件很多低级回归在本地就能发现。如果团队对这部分有更高要求还可以在本地或 CI 里加一条轻量级的“静态检查”。比如用 Playwright 对 Storybook 页面截图保存到本地临时目录不需要上传到云端只是用于快速确认页面能正常渲染、没有白屏、没有明显控制台错误。这类检查不能替代视觉回归测试但可以拦截掉大部分“启动即失败”的问题避免云端空跑。云端视觉测试应该用来解决“自动化对比历史基线”这件事而不是用来代替工程师开发时的基本检查。把低价值的确认工作放在本地把高价值的对比工作留给云端额度消耗会更合理。4.2 只 push 有变化的配置到云端有些视觉测试平台支持自动识别“哪些 Story 真正发生了变化”比如根据构建产物和源码依赖关系做增量分析。类似能力在不同平台叫法不同Chromatic 里有 TurboSnap 这样的增量方案。思路是一致的通过依赖分析只重跑受影响的组件而不是每次都全量重跑。如果平台提供了这类能力优先打开。打开之后即使你本地全量构建 Storybook云端也可能只会抓取真正发生变化的 Story。这能让常规 PR 的快照量大幅下降。如果平台没有增量能力就需要在 CI 侧自己实现“先判断是否真的要跑”的逻辑。比较稳妥的做法是分成两步# 示例CI 流程拆分 steps: - run: npm install - run: npm run build-storybook - run: node scripts/decide-visual-test.mjs id: decide - run: npx chromatic if: steps.decide.outputs.run yes这个流程的含义是先构建本地 Storybook再根据变更文件决定是否调用 Chromatic 命令。如果决定结果是 skip就直接跳过云端上传。这样可以保证只有真正有视觉变化风险的提交才消耗云端额度。有些人会觉得“多跑一次 build-storybook”浪费时间但它用的是 CI 机器资源通常比云端快照额度便宜得多。对于账单敏感的团队值得用一点 CI 时间换云端消耗。4.3 独立构建任务控制并发很多平台的套餐里并发数会影响体验但真正烧额度的是快照总数。如果你观察到某个时间段快照消耗异常高除了看测试配置还要看 CI 触发频率是否过高。我建议把视觉测试从常规单元测试里拆成独立任务。不要让每次 push 都同步跑视觉测试也不要让多个分支在同一时间并行触发大量全量测试。更好的做法是PR 打开时只对变更组件做增量视觉测试。main 分支合并时或发布前跑一次完整回归。临时分支、草稿 PR、机器人提交的分支尽量跳过或手动触发。这样可以避免一个峰值时段内十几个分支同时向云平台上传快照。对账单最直接的贡献是减少了正常开发过程中大量重复的全量消耗。同时也能降低平台侧的网络波动和超时重试间接减少额外快照。5. 拿一个模拟场景估算效果为什么能达到 10 倍差距5.1 估算方法要判断能不能实现 10 倍下降不要只看单次优化要看多个因素的乘积。先设置一个典型场景。假设项目有 50 个组件每个组件平均 8 个 Story总共 400 个 Story。优化前每个 Story 使用 4 个视口、3 种浏览器。那么一次全量测试的基准快照数是400 Story × 4 视口 × 3 浏览器 4800 张快照。如果团队每周有 20 次全量测试月消耗大约是 96000 张快照。即便平台免费额度再高这个量级也会很快进入付费阶段。优化分三步第一把大部分组件的浏览器收敛为 1 个基础视口收敛为 2 个。那么同样 400 个 Story 的全量快照变为400 Story × 2 视口 × 1 浏览器 800 张快照。第二把 PR 阶段的全量测试改为按变更组件过滤。假设一个 PR 平均影响 50 个组件里的 10 个那么 PR 阶段每次消耗10 个组件 × 8 Story × 2 视口 × 1 浏览器 160 张快照。第三只在合并主干或发布前跑完整回归。如果每个月有 20 次 PR外加 4 次全量回归总消耗大约是20 × 160 4 × 800 3200 3200 6400 张快照。对比原来的 96000 张快照节约效果接近 15 倍。即使你的项目没有 50 个组件只要同时做到了浏览器收敛、视口收敛、按变更跑测试数量级下降依然明显。这不是一个精确的官方数字只是一个用来建立预期感的估算框架。你可以把自己的组件数、Story 数、浏览器数和 PR 次数套进去算出你的项目理论上能省多少。5.2 哪些项目最受益这套优化思路并不是对所有项目都同样有效。如果项目只有 10 个组件测试量本来就很小再怎么减可能也就是从 200 张降到 50 张绝对金额变化不大。但如果你的项目满足以下条件10 倍优化是现实目标组件库或页面组件数量超过 50。每个组件下有大量状态 Story。项目里配置了多个浏览器或多个视口。CI 对每次 push 都执行全量云端测试。团队有多个开发分支同时推进。这类项目的快照成本通常不是线性上涨而是随着组件数量、Story 数量、浏览器数量和触发次数同时上涨。反过来只要把其中两三个变量压下来费用就会快速回落。如果项目只有一个静态展示页用不上太复杂的策略。把 Story 数量控制在最小必要范围然后定期跑一次全量就可以。6. 边界、坑点和长期维护建议6.1 省额度不等于省测试覆盖率优化快照数量时最怕的是为了省钱把关键测试也删了。视觉回归测试的核心价值在于守护那些“不该变化”的样式如果删掉了回归风险会上升。尤其是核心组件和关键业务状态宁可多留一个 Story也不能因为账单焦虑全部砍掉。我比较推荐的做法是“分级守护”日常 PR 只跑核心组件和变更组件的快照合并到主干前跑全量回归。这样日常开发负担小但发布前仍然会做一次完整检查。也就是说省的是“重复验证”的量不是“关键验证”的量。另外视觉测试并不需要覆盖所有 UI 状态。像“数据已加载但有 1000 条记录”“列表为空”“接口报错”这类状态应该由单元测试或端到端测试去覆盖。视觉测试只需要验证它们渲染出来的样式是否正常不需要为每种数据长度单独造快照。6.2 常见误区和排查顺序优化过程中很容易踩几个坑我单独列一下。第一个误区是只改 Story 数量不改浏览器和视口。Story 减掉 30%但浏览器仍有 3 个视口仍有 4 个最终快照量下降不明显。浏览器和视口是倍数放大器优先处理这个部分效果更直接。第二个误区是本地过滤脚本太保守导致很多本该跑的组件被跳过了。比如脚本只匹配了src/components但组件实际在packages/ui/src下那么整个视觉测试都会静默失效。判断标准是过滤后要能在平台报告里看到对应组件的快照而不是只剩下一个空测试集。第三个误区是只关注单次 build不关注触发频率。单次从 4800 张降到 800 张已经很好但如果每天仍然触发 20 次全量测试总的额度消耗还是偏高。触发频率要和单次快照量同时优化。如果账单突然异常建议按这个顺序排查先看最近几天的 build 数量有没有因为临时分支、重复推送导致大量重复触发。再看单次 build 的快照总量和之前相比有没有明显增长。查看浏览器和视口配置确认是否有人为了提高兼容性把全局矩阵扩大。查看 Story 数量和新增 Story确认是否有人在日常开发中不断添加低价值 Story。最后看失败重试次数如果网络或资源问题导致反复抓取既要解决运行环境也要优化并发。这个顺序能帮你快速定位是“流程问题”还是“配置问题”而不是每次都在账单页面里猜。6.3 长期维护建议优化一次并不难难的是让快照数量不反弹。我把长期维护建议总结成几点。第一把 Story 评审写进开发规范。新增 Story 时如果不是新增视觉状态就尽量复用已有 Story或使用参数组合展示。一个组件最多保留多少个视觉 Story可以写一个参考值超了就提醒团队先做合并。第二用快照预算做 CI 检查。如果你能拿到上一次 build 的快照总数可以在 CI 脚本里设置一个阈值。当快照数量超过预算时直接失败或给出警告让开发者在合入代码前意识到测试集变大了。第三周期性清理低价值 Story。每隔一两个迭代检查一次 Storybook 目录和视觉测试报告。长期没有变更、没有实际业务使用、维护者自己都不确定的 Story可以标记为跳过或直接删除。第四把全量回归固定在发布流程里。日常 PR 可以省但发布前一定要保证跑一次完整视觉测试。这样可以避免“日常开发时很省但上线前才发现样式回归”的尴尬。回到标题里的 10 倍本质上不是靠某一个魔法开关而是把 Story 数量、浏览器数量、视口数量、触发频率、增量策略五个方面都做减法。单个因素可能给你带来 1.5 倍到 3 倍的收益乘在一起才能真正改变账单量级。这种思路并不绑定 Chromatic换到任何视觉测试工具都成立。关键不是工具叫什么而是你有没有真正控制住“快照点”这个最核心的成本单位。