组件库发布前怎么验收？状态、示例与兼容性检查

先给结论：组件库发布前的验收应围绕“每个状态能否使用、示例能否照做、旧实例会不会坏”三件事展开。下面以订单后台的“提交订单”按钮候选版本为例，在Pixso 创建组件页面对应的组件工作流中组织证据；文章中的发布门禁是团队流程，不把它写成产品自动检查。

先锁定候选版本和消费场景

把候选版本标为 Button/Primary/v3，同时保留 v2 供旧页面对照。发布说明先列出 3 个真实消费场景：订单提交、批量导出和二次确认弹窗。每个场景记录按钮文字、是否允许重复点击、请求失败后是否可重试，以及旧实例是否含有自定义图标。没有消费场景的“看起来完整”不算通过。

状态矩阵要能被别人复现

不要只放一张“按钮全状态”雪碧图。为每个状态写触发条件和离开条件：聚焦来自键盘移动时必须有可见焦点环；加载状态在请求完成、超时或取消时分别回到成功、错误或可重试；禁用状态说明是权限不足还是前置字段未填。错误不能只换红色，还要有文本和可定位的修正动作。

示例页面至少串起一条完整路径：订单金额为 0 时按钮保持可见但不可提交；补齐金额后变为可聚焦；点击后显示“提交中”，服务返回 409 时显示“库存已变化，重新检查”并允许重试。把这条路径放入组件文档，评审人才能按相同步骤复现。

检查设计、实现和文档是否说同一件事

设计稿中的属性名、默认值和状态应与交付说明逐项对应。若设计稿写 loading=true 会锁定按钮宽度，示例页面和实现说明就不能把它描述成“自动收缩”。对 12 个旧实例逐个抽查：图标位置、长文案、深色背景和自定义宽度都要过一遍。键盘操作至少验证 Tab 可到达、Enter 或 Space 有预期动作，并且焦点环不被裁切。

为破坏性改动准备回滚和重开路径

如果 v3 删除了旧的 size=small 或改变图标插槽命名，不要用“兼容处理”一笔带过。把影响实例列成迁移表，给出截止版本；在迁移完成前继续提供 v2。发布候选验收不通过时，保留 v2 的可用入口，记录缺陷编号、复现步骤和责任人，修正后只重跑受影响的状态，不重做整套检查。

四个画板完成发布门禁

在 Pixso 画布中放置“状态矩阵”“消费示例”“旧实例对照”“发布与回滚记录”四个画板。验收人按矩阵抽查 7 个状态、按示例重走 3 条路径，再对照 12 个旧实例的迁移结果；任一高风险缺口都把候选标为待修订。只有状态、文档、实例和回滚入口都能追溯到同一个版本号，才将候选交给发布负责人。