建站方案说明：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /67686d54d638.html
📄
建站方案说明：同一组件在不同页面表现不同时怎样构造验收样例
先给有条件的结论：如果同一组件在不同页面的差异只来自上下文数据或布局约束，验收样例应把组件拆成“固定输入 + 页面上下文 + 可观察输出”三部分，分别覆盖；如果差异来自组件本身在不同页面走了不同代码路径，那么继续加页面样例只会掩盖问题，必须先统一调用方式。判断属于哪一种，靠的是对比同一输入在两个页面中的输出，而不是靠页面数量堆样例。
先判断差异来自上下文还是来自组件实现
同一组件在列表页和详情页表现不同，常见原因有两类。第一类是上下文差异：容器宽度、父级字号、传入的数据字段、是否处于懒加载区域，这些都会改变渲染结果，但组件代码只有一份。第二类是实现差异：两个页面引用了不同版本、不同封装层，或者其中一个页面在组件外又包了一层条件判断。
区分方法很直接：把两个页面的组件输入改成完全一致，包括数据、容器宽度和父级样式，再看输出是否仍然不同。如果一致了，说明差异来自上下文；如果仍然不同，说明组件实现或调用链存在分叉。这个判断决定了验收样例的构造方向，先做这一步能避免后面白写一批用例。
上下文差异：按变量维度构造最小对照样例
确认差异来自上下文后，验收样例不应按“页面”来写，而应按“变量组合”来写。把影响输出的上下文变量列出来，每个变量取两个有代表性的值，构造最小对照。例如容器宽度取窄和宽两档，数据字段取完整和缺省两档，组合成四组样例，而不是把每个页面各截一张图。
每个样例要写清楚三件事：输入是什么、预期可观察输出是什么、判定依据是什么。判定依据要能被人独立复核，比如“字段缺省时占位文案出现且不撑破容器”，而不是“看起来正常”。
- 输入：明确写出传入的数据字段和容器约束，不写“正常数据”。
- 预期输出：写可观察结果，如元素是否出现、是否换行、是否溢出。
- 判定依据：写清用什么方式确认，如目视检查边界、检查元素是否超出容器。
这样构造的样例数量可控，且每个样例都能解释它覆盖了哪个变量。当后续有人改动组件，能快速定位是哪一组上下文假设被打破。
实现差异：先统一调用方式，再谈样例
如果对照测试显示组件实现存在分叉，此时增加页面级验收样例的收益很低，因为样例会同时受实现差异和上下文差异影响，失败时无法判断原因。正确动作是先统一调用方式：确认两个页面引用的是同一份组件代码，去掉页面外多余的包装层，再重新跑一次对照。
这个动作的结果会直接影响下一步。如果统一后差异消失，说明之前的“不同表现”是调用方式造成的，验收样例只需覆盖统一后的组件加不同上下文；如果统一后差异仍在，说明组件内部对上下文有隐式依赖，需要把这种依赖显式化，比如把影响布局的假设写成参数，再为参数取值构造样例。
一个假设例子：按钮组件在两页宽度不同
假设一个按钮组件在列表页显示为紧凑样式，在详情页显示为通栏样式。先做对照：把详情页的容器宽度改成与列表页一致，如果按钮随之变紧凑，说明差异来自容器约束，验收样例就按容器宽度分档来写。如果宽度一致后按钮仍为通栏，说明详情页可能引用了另一份样式或额外类名，此时应先统一引用，再重新判断。
这个例子的价值在于它给出了可执行顺序：先对照，再分类，再决定是加样例还是先改调用。跳过对照直接按页面写样例，很容易把实现问题误判为上下文问题。
会使结论失效的反例与下一步动作
上述结论有一个明确的反例：当差异只在特定数据组合下出现，而该组合又依赖页面特有的数据来源时，单纯统一输入可能无法复现问题，因为页面数据本身无法在另一页面等价构造。这种情况下，按变量构造最小对照的前提不成立，需要先为组件定义一份与页面解耦的输入契约，再基于契约构造样例。
下一步动作建议固定为：先做一次输入一致的对照测试并记录结果，再根据结果选择“按上下文变量构造样例”或“先统一调用方式”。把这次对照结果和选择理由写进建站方案说明的验收部分，后续维护者才能理解样例为什么这样分组，而不是照抄一组看不出意图的页面截图。
