快速建站：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4e0fcfef7cc3.html
📄
快速建站：同一组件在不同页面表现不同时怎样构造验收样例
先做一件事：把差异定位到“输入、容器、渲染时序”三者中的哪一个，再决定验收样例保留、改写还是退出。同一按钮、卡片或表单组件在A页正常、B页错位，通常不是组件本身坏了，而是它在B页拿到了不同的宽度约束、字体上下文或异步数据。验收样例要能复现“差异成立的条件”，而不是只截一张正常页面的图。
先判断差异属于哪一类，再决定样例去留
把现象分成三类，处理方式完全不同。
- 输入差异：同一组件在不同页面收到的文案长度、图片比例、字段数量不同。此时应保留原组件，改写样例数据，把最长和最短两种内容都写进验收集。
- 容器差异：父级宽度、栅格列数、内外边距不同，导致组件被挤压或拉伸。此时应改写容器的约束规则，而不是改组件内部样式。
- 时序差异：组件依赖的字体、图片或接口数据到达时间不同，首屏出现跳动或占位错乱。此时应保留组件，改写加载策略，并把“慢一档”的网络条件写进样例。
只有当同一组件在相同容器、相同输入下仍表现不一致，才考虑退出这个组件、换用更简单的实现。退出是最后选项，因为替换会带来新的未知差异。
验收样例要固定哪些变量
样例的价值在于可重复。每条样例至少固定四组变量，缺一组就可能把偶发现象当成结论。
- 视口宽度：至少取业务真实流量的窄、中、宽三个档位，而不是随手拖动窗口。
- 内容负载：用真实业务里出现过的极值，例如最长的商品名、最多的标签数。
- 容器上下文：记录该页面的栅格列数、父级最大宽度和是否处于弹层或侧栏内。
- 数据状态：区分加载中、加载完成、加载失败三种，尤其是失败态常被忽略。
把每条样例写成“页面路径 + 视口 + 内容负载 + 数据状态”的组合，任何一项变化都算新样例。这样做的直接结果是：当有人报告“B页又坏了”，你能立刻判断是新增了内容极值，还是容器被改过。
一个注明假设的短例子
假设某卡片组件在列表页显示正常，在详情页侧栏中文字溢出。按上面的分类，这属于容器差异：侧栏可用宽度更小。此时保留组件，改写容器的宽度下限，并补一条样例：视口取窄档、内容取最长标题、数据取加载完成。若改写后仍溢出，再检查是否卡片内部用了固定像素宽度——那才是组件该改的地方。这个判断顺序能避免一上来就重写组件，把改动范围控制在一处。
什么条件下该改写，什么条件下该退出
改写适用于差异有明确触发条件、且该条件在业务中合理存在的情况。例如详情页侧栏本来就窄，组件适配窄容器是正常需求。
退出适用于差异来自组件对外部环境的隐式依赖，且这种依赖无法在样例中稳定复现。例如组件依赖某个全局样式或全局脚本的加载顺序，而不同页面的加载顺序由历史遗留决定。此时继续修补会不断引入新的特例，换成不依赖全局状态的实现更可控。
判断依据不是“改起来麻烦”，而是“触发条件是否可枚举”。可枚举就改写，不可枚举就退出，并把退出原因写进验收记录，避免下次又把它加回来。
验收通过后要留下什么
通过不等于结束。把本次确认的样例组合归档，并标注它对应的容器和内容极值。下一次有人改动公共样式或栅格，先用这批样例回归一遍。如果某条样例开始失败，先看它固定的哪个变量被改动，再决定是修页面还是修样例。这样验收样例就从一次性检查变成了可持续使用的判断依据。
