长治网页制作，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ebb2e430c4a8.html
📄
长治网页制作，同一组件在不同页面表现不同时怎样构造验收样例
结论先说：不要为每个页面单独写一份验收清单，而应把组件拆成“结构、数据、上下文”三层，固定前两层、只让上下文变化，用同一组样例跑遍所有调用位置。这样做的代价是前期要多花时间梳理调用关系，但能避免上线后反复出现“首页正常、详情页错位”的返工。如果组件本身没有稳定边界、页面之间连数据来源都不同，这套方法会失效，此时应先统一数据契约，而不是急着写样例。
先判断差异来自组件还是来自上下文
同一组件表现不同，通常只有两类原因。第一类是组件自身在状态或尺寸上存在条件分支，比如折叠态与展开态、有无图片、文本长度不同。第二类是调用它的页面提供了不同的容器宽度、父级样式或数据密度。区分方法很直接：把组件单独放进一个中性容器，喂入各页面的真实数据，看差异是否仍然存在。
- 差异仍在：问题在组件内部，验收样例要覆盖这些状态组合。
- 差异消失：问题在页面上下文，验收样例要覆盖容器和继承条件。
- 两者都有：先修组件，再固定上下文样例，否则每次调页面都会牵动组件。
这个判断决定了后面样例的构造方向，也决定了修复成本由谁承担。
两种做法：全页面截图比对，还是组件级样例
全页面截图比对实现快，适合页面数量少、改版周期短的场景。它的代价是脆弱：任何无关区域的改动都会让比对失败，而且失败信息只告诉你“这块不一样”，不告诉你组件在什么条件下坏掉。组件级样例前期投入大，需要先列出调用位置和数据形态，但每次回归只跑组件本身，定位快、维护成本随页面数量增长而摊薄。
选择条件可以这样看：如果组件被三个以上页面复用，或同一页面内出现多次，优先做组件级样例；如果只是一次性页面、后续不再改动，截图比对更划算。假设一个站点的商品卡片同时出现在首页推荐、列表页和详情页的相关推荐中，那么组件级样例是更合理的投入，因为三处容器宽度和图片比例都不同。这个例子只用于说明比较方法，不代表任何实际站点。
构造样例的三层结构
把每个用例写成三部分，可以避免样例之间互相污染。
- 结构层：组件的最小可渲染形态，例如只有标题、只有图片、标题加图片加按钮。
- 数据层：字段长度和内容类型，例如超长标题、缺图、多标签、数字与文字混排。
- 上下文层：容器宽度、父级字号、是否处于折叠区域、相邻元素间距。
固定结构层和数据层，只替换上下文层，就能复现“同一组件在不同页面表现不同”。反过来，固定上下文层、替换数据层，能找出内容驱动的溢出和换行问题。两组样例都要有，但不要混在一张清单里，否则失败时无法判断是哪一层引起的。
一个可执行的短例子
假设组件是一个信息卡，在列表页正常，在详情页侧栏被压窄后文字溢出。可以这样写样例：结构层固定为“标题 + 摘要 + 链接”，数据层固定为“标题二十字、摘要六十字”，上下文层分别设为窄容器和宽容器两种。跑完后如果只有窄容器失败，说明需要给组件加最小宽度或换行规则，而不是去改详情页的布局。这个动作的结果会直接影响下一步：若加最小宽度后宽容器出现空白过多，就要回到数据层，检查是否该在窄容器下减少展示字段。
样例要注明假设条件，比如容器宽度的取值依据、数据长度的来源。没有假设的样例，换个人跑就会得出不同结论。
什么情况下这套方法不成立
如果不同页面调用组件时传入的数据结构本身就不一致，比如一处传数组、一处传对象，那么再多的视觉样例也无法稳定复现问题，因为差异来自契约而非渲染。此时应先统一数据契约，再回到样例构造。另一个失效条件是组件依赖运行时才能确定的外部状态，例如登录态或异步加载结果，这类情况需要把状态作为样例维度显式列出，而不是靠人工在页面上碰运气。
下一步动作很明确：先列出该组件的全部调用位置，标注每个位置的容器条件和数据形态，然后按上面的三层结构写出第一组样例。跑完第一组后，根据失败集中在哪一层，再决定是修组件、修上下文，还是先统一数据契约。
