建站周期：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6874bdc50150.html
📄
建站周期：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要继续在出问题的页面上反复刷新，也不要直接判定组件有缺陷。正确做法是构造一组只改变一个条件的对照页面，把“组件自身、页面上下文、数据来源、加载顺序”四类解释分开。验收样例的目标不是证明谁对，而是让每一种解释都有可核对的证据，再决定是改组件、改页面，还是改交付标准。
下面用一个假设情境贯穿：某项目在交付前发现，同一个商品卡片组件在列表页显示正常，在详情页的推荐位却出现图片比例被拉伸、按钮位置下移。团队最初怀疑组件代码写坏了，但列表页用的是同一份组件文件。这个矛盾本身就是最有价值的线索。
先把“不同页面”拆成可单独改变的条件
同一组件表现不同，通常不是组件本身随机变化，而是它进入不同页面后，外部条件变了。构造验收样例时，先把可能变化的量列出来，并且每次只放开一个：
- 容器宽度与父级布局：列表页可能是等宽网格，推荐位可能是流式窄栏。
- 传入的数据：列表页的图片有固定尺寸字段，推荐位的数据可能缺这个字段。
- 样式作用域：页面级样式是否覆盖了组件内部的类名或标签选择器。
- 加载与渲染顺序：推荐位是否在异步数据返回后才插入，导致尺寸计算发生在图片加载之前。
- 交互状态：推荐位是否默认处于某个折叠、懒加载或轮播状态。
把这张清单变成验收样例的骨架：每个样例只改一项，其余保持与正常页面一致。这样出现差异时，能直接指向被改动的那一项，而不是靠猜测。
用最小对照页代替在真实页面里反复试
在真实页面里改样式、改数据，很容易一次动了好几处，最后没人说得清是哪一步生效。更稳的做法是新建一个不对外发布的对照页，只放被测组件，并给它套上与出问题页面相同的容器结构。
假设情境继续：团队建了三个对照页。A 页用列表页的容器宽度和完整数据；B 页只把容器换成推荐位的窄栏，数据不变；C 页容器不变，只把数据里的图片尺寸字段去掉。结果 A 正常，B 出现按钮下移，C 出现图片拉伸。此时可以判断：按钮问题与容器宽度有关，图片问题与数据字段缺失有关，两者是不同原因，不该用同一个修复动作处理。
这个动作的价值在于：它把“组件坏了”这个笼统判断，拆成了两个可分别验证的具体条件。下一步的修复方向也随之确定——一个改布局约束，一个补数据校验或默认值。
区分“组件缺陷”和“页面契约未满足”的证据
很多人会直接把差异归为组件缺陷，但验收样例要回答的是：组件对使用方有没有明确要求，页面有没有满足这些要求。可以用下面这组可区分证据来判断：
- 如果只改容器宽度就复现，且组件没有声明最小宽度或自适应规则，属于组件对外部条件的假设没有被写进契约。
- 如果只改数据就复现，且组件没有对缺失字段做兜底，属于组件对输入数据的假设没有被写进契约。
- 如果两者都改才复现，说明存在组合条件，验收样例需要保留这个组合，而不是拆开分别测完就结束。
- 如果怎么改都不复现，只在真实页面出现，则要怀疑页面上的第三方脚本、全局样式或异步时序，而不是组件本身。
这里的“契约”不是法律文件，而是组件交付时应该写清的使用前提：需要什么容器、需要哪些数据字段、缺省时如何表现。把它写进验收样例，后续页面接入时就能提前发现不匹配，而不是等到上线前才发现。
把验收样例写成可重复执行的一小组，而不是一次性排查
排查完成后，如果只留下“这次修好了”的结论，下一个页面接入时同样的问题会再来一次。更值得做的是把这次用到的对照条件固化成一小组合规样例，纳入交付检查。
例如，针对这个商品卡片组件，可以固定三个样例：宽容器加完整数据、窄容器加完整数据、宽容器加缺失图片尺寸字段。每次组件或页面布局有改动，先跑这三个样例，记录每个样例下图片比例和按钮位置是否符合预期。这样做的结果不是保证永远不出问题，而是让“不同页面表现不同”这件事在接入阶段就暴露，而不是留到验收末期。
需要说明适用条件：这套方法适合组件被多个页面复用、且页面容器或数据来源不一致的项目。如果组件只在一个固定容器里使用，数据字段也由同一处提供，那么对照样例可以简化，重点放在数据边界和加载时序上即可。
决定下一步之前，先确认差异是否稳定可复现
还有一种容易被忽略的情况：差异只在某些时候出现。这时不要急着下结论，先确认它是否稳定。可以固定同一组样例，在不同时间、不同网络条件下重复执行几次，记录每次的结果。
如果差异时有时无，合理解释可能包括图片尚未加载完成就进行了尺寸计算、异步数据返回顺序不同、或页面上的其他脚本在特定时机修改了样式。这些解释指向的是时序问题，而不是组件逻辑错误。此时下一步动作应该是调整加载或渲染顺序，并为此单独设计一个样例，而不是继续修改组件样式。
反过来，如果差异每次都能稳定复现，并且只与某一个被改动的条件相关，就可以把修复范围收窄到那个条件对应的代码或数据约定上。无论哪种情况，验收样例的作用都是让判断有依据，让下一步动作有明确对象，而不是在多个页面之间来回猜测。
