品牌网站设计，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8865a3934c64.html
📄
品牌网站设计，同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要为“组件本身”写一份通用验收样例，而要为“组件所处的页面条件”各写一份。同一导航、卡片或表单在首页正常、在活动页错位，通常不是组件坏了，而是它继承的容器宽度、内容长度、加载顺序或样式作用域不同。验收样例要固定这些条件，再比较输出，才能判断该改组件、改页面，还是改两者之间的约定。
先分清两种解释：组件缺陷，还是上下文差异
表现不同，至少有两种成立条件不同的解释。
解释一：组件确实有缺陷。它在某种输入下必然出错，只是首页恰好没触发。例如卡片组件在标题超过两行时高度计算失效，首页标题短，活动页标题长，于是活动页错位。这种情况下，改页面只是掩盖问题，换一个长标题仍会复现。
解释二：组件没问题，是页面上下文不同。组件被放进不同宽度的栅格、不同的层叠上下文，或前后元素占用了不同空间。例如同一按钮组在窄栏里换行，在宽栏里不换行。组件按自身规则运行正确，是页面没有提供它需要的空间。
两种解释的处置方向相反：前者改组件并回归所有引用处，后者改页面或补充使用约定。所以验收样例的第一件事不是记录“哪里不一样”，而是记录“哪些条件不一样”。
用一组可区分的证据定位原因
能区分上述两种解释的证据，是控制变量后的复现结果。做法是：把组件从两个页面中抽出来，放进同一个最小容器，只保留一个变量。
- 固定容器宽度、字体、内容长度，只换页面。若表现一致，说明差异来自页面上下文。
- 固定页面，只把内容长度加倍。若错误出现，说明组件对内容长度缺少约束。
- 固定页面和内容，只改变加载顺序或异步数据的到达时机。若错误时有时无，说明问题在渲染时序，而不是静态样式。
假设一个例子：某卡片在列表页正常，在详情页侧栏溢出。把侧栏宽度设为与列表页一致后恢复正常，这就支持“上下文差异”而非“组件缺陷”。反过来，若宽度一致仍溢出，则应回到组件内部检查其最小宽度设定。这个例子只说明比较方法，不代表任何真实项目结论。
验收样例要写清的四类条件
每个样例至少包含以下字段，缺一项就难以复现：
- 容器条件：父级宽度、内边距、是否处于弹性或网格布局。
- 内容条件：标题与正文的最短、典型、最长三种长度，图片有无及宽高比。
- 状态条件：默认、悬停、聚焦、禁用、加载中、空数据、错误。
- 环境条件：视口宽度区间、字体是否加载完成、数据是同步还是异步注入。
把每个页面按这四类条件填一遍，往往就能看出：两个页面的差异集中在哪一类。差异集中处，就是验收样例最该覆盖的地方，而不是把所有组合穷举一遍。
旧内容退出时，样例要保留什么
当旧页面、旧系统或旧合作关系要退出，组件仍可能被保留。此时验收样例的作用是划清保留边界：哪些条件属于仍要支持的范围，哪些随旧页面一起作废。
实际动作是：先列出该组件当前被引用的所有页面，标注每个页面是保留、替换还是下线。对保留的页面，按上面的四类条件各写一条样例；对下线的页面，不写样例，但要记录它曾触发的特殊条件，避免日后有人误以为这些条件仍被支持。这样做的结果是，组件改动的回归范围被压缩到真实仍在用的页面，而不是全站重测。下一步的取舍也随之清楚：如果保留页面的条件高度分散，与其继续维护一个万能组件，不如拆成两个职责更窄的组件。
样例通过之后，还要确认约定
样例全部通过，只能说明这些条件组合下表现一致，不能说明组件对未知页面也安全。因此还要补一条约定：组件对外声明它依赖的最小宽度、可接受的内容长度上限，以及是否要求父级提供定位上下文。页面在接入时若满足不了这些前提，应改页面而不是改组件去迁就。
把这条约定写进验收样例的说明部分，下一次出现“同一组件在不同页面表现不同”时，就能先对照约定判断是接入方越界，还是组件自身需要修正。验收样例的价值不在数量，而在于它让每次差异都能被归因到某个明确条件，并据此决定下一步是改组件、改页面，还是退出旧内容。
