网站建设流程：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4c47886eb765.html
📄
网站建设流程：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要用单个页面的正常表现作为组件验收依据，而要把组件放进它实际出现的页面类型里，各取一个代表性样例，分别记录输入条件、容器约束和渲染结果。当两种条件下的差异能被稳定复现，验收结论才成立；否则只能算个别样本通过，不能推广到全站。
先分清差异来自组件本身还是页面环境
同一组件表现不同，常见原因有三类：一是页面容器宽度、栅格或内边距不同；二是页面传入的数据形态不同，比如字段缺失、文案超长、图片比例不一致；三是页面加载顺序或样式覆盖不同。验收样例要能区分这三类原因，否则改完一处，另一处仍会复发。
可用的区分证据是：把同一份数据分别放进两个页面容器中渲染。如果差异消失，问题在容器；如果差异仍在，问题在数据或组件内部逻辑。这个动作的结果直接决定下一步——前者改页面布局约束，后者改组件默认值和兜底规则。
两种条件下分别构造样例的选择依据
条件一：组件在窄容器和宽容器中都被使用。此时验收样例要各取一个最窄和一个最宽的页面作为边界，而不是取中间值。选择依据是布局约束的极值最容易暴露换行、溢出和截断问题。
条件二：组件只在一个固定容器中使用，但数据来源不同。此时验收样例要按数据极值构造：最短内容、最长内容、字段缺失、字段类型异常各一份。选择依据是数据形态比容器更可能触发例外。
两种条件不能混用同一套样例。窄宽容器场景下，数据用常规值即可；数据极值场景下，容器固定不变。混用会让差异原因无法归因，验收记录也失去比较价值。
一个可执行的样例构造动作
假设某卡片组件在列表页显示正常，在详情页侧栏出现文字溢出。可以这样构造样例：
- 在列表页和详情页各选一个真实存在的使用位置，记录容器可用宽度和高度约束。
- 准备同一份数据，包含一条常规文案和一条明显超长文案。
- 分别渲染四组组合：列表页加常规、列表页加超长、详情页加常规、详情页加超长。
- 记录每组是否出现溢出、截断、换行异常或高度塌陷。
如果只有“详情页加超长”这一组异常，说明组件对窄容器下的超长内容缺少兜底，验收样例应保留这一组作为回归用例。如果四组都异常，说明组件默认样式本身有问题，样例范围要扩大到所有使用位置。这个动作的结果会影响下一步：是补一条边界规则，还是重做组件的基础样式。
不能直接照搬的边界
以下情况不适合把上述样例直接推广到全站：
- 组件在某个页面被局部样式覆盖，且该覆盖是页面特有需求，不应回写到组件默认值。
- 页面使用了不同的渲染模式，比如服务端渲染与客户端渲染混用，此时差异可能来自加载时机而非组件逻辑。
- 数据来自不同接口，字段命名或层级不一致，此时应先统一数据适配层，而不是改组件。
- 差异只在特定浏览器或特定缩放比例下出现，验收样例需要补充环境条件，不能只记录页面名称。
这些边界的共同点是：差异的根源不在组件本身，而在页面环境或数据链路。把这类差异写进组件验收样例，会导致组件被迫承担不属于它的约束，后续维护成本反而上升。
验收记录要写到什么程度才算可复现
每条样例至少记录四项：使用位置、容器约束、输入数据特征、实际渲染结果。缺少任何一项，其他人无法判断这条样例是否仍然成立。记录的目的是让下一次改动后能快速比对，而不是留一份好看的文档。
当样例能稳定复现差异时，验收结论应写成“在条件A下通过，在条件B下不通过”，并注明条件B是否属于合理使用范围。如果条件B本身就是不该出现的用法，结论应是限制使用范围，而不是要求组件适配。这一步决定了后续是改代码还是改使用规范。
