网站建设策略：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5747d3e1d697.html
📄
网站建设策略：同一组件在不同页面表现不同时怎样构造验收样例
先把组件从页面中拆出来，为它单独建立可复现的最小验收样例，再逐步加回页面条件，观察哪一步开始出现差异。这样做的原因是：同一组件在不同页面表现不同，通常不是组件本身时好时坏，而是页面给它提供的上下文不同。只在一个页面里反复刷新、反复调样式，往往找不到真正变量。
先分清两类解释：组件状态被污染，还是页面上下文不同
第一类解释是组件状态被污染。比如同一组件实例被多个页面复用，前一个页面留下的筛选条件、展开状态、异步数据或缓存结果，带进了后一个页面。表现上像是“同一个组件在不同页面不一样”，实际是运行顺序和共享状态在起作用。
第二类解释是页面上下文不同。组件代码没变，但父容器宽度、栅格列数、字体继承、层叠顺序、页面加载顺序、数据到达时机不同。表现上同样像组件不稳定，实际是组件对外部条件的假设没有被写进验收样例。
这两类解释对应不同的修复方向。前者要隔离状态，后者要固定上下文。若一开始不区分，很容易把上下文问题误判成组件缺陷，反复改组件内部逻辑，结果在原来的页面好了，换一个页面又坏。
能区分两类解释的证据：控制变量后看差异是否跟随组件移动
可以做一个假设例子。假设一个筛选组件在列表页正常，在详情页侧栏中初始选项错位。先不改代码，只做三件事：
- 把同一个组件单独放进一个空白测试页，只给最小容器和固定宽度，观察是否仍错位。
- 在列表页和详情页分别记录组件挂载前后的容器宽度、可用高度、父级样式和初始数据。
- 把详情页的容器条件复制到测试页，再把列表页的条件复制到测试页，各跑一次。
如果错位只跟着页面走、不跟着组件走，说明问题在页面上下文；如果错位跟着组件实例走，换到空白页仍出现，说明问题在组件状态或组件自身假设。
这里的关键动作是“复制条件后重跑”。它的结果会直接决定下一步：若复制详情页条件后测试页复现，就应把该条件写进验收样例；若复制后仍不复现，就要继续查数据到达顺序、共享状态或事件绑定次数。
构造验收样例时，把页面条件写成可替换的变量
验收样例不应只写“组件显示正常”，而应写成一组可替换条件。至少覆盖以下维度：
- 容器条件：固定宽度、流式宽度、最小高度、是否处于栅格或弹性布局中。
- 数据条件：空数据、一条数据、多条数据、延迟返回、返回顺序与页面其他请求交错。
- 状态条件：首次挂载、二次进入、带缓存进入、从其他页面返回。
- 交互条件：初始渲染后立即操作、等待一段时间后操作、连续快速操作。
这些条件不是越多越好，而是要先找出“哪个条件一换，表现就变”。可先固定其余条件，只替换一个变量，观察结果。这样得到的证据比一次性堆很多条件更清楚。
一个可执行的排查顺序与判定依据
建议按以下顺序推进，每一步都留下可比较的结果：
- 在问题页面记录组件挂载前后的容器尺寸与父级样式，作为基线。
- 把组件移到最小测试页，只保留必要依赖，观察是否复现。
- 若不复现，逐项加回基线条件：先加容器尺寸，再加数据时序，再加页面级样式。
- 记录“加到哪一项开始复现”。这一项就是验收样例必须覆盖的条件。
- 把该条件写入组件验收样例，并注明假设：在何种容器、何种数据时序下应表现一致。
判定依据可以概括为：差异跟随页面条件移动，则修上下文或把上下文纳入组件契约；差异跟随组件实例移动，则修状态隔离或组件内部假设。两种结论会导向不同的验收样例写法，不能混在一起。
验收样例要能回答“换一个页面还成立吗”
最终验收样例至少应包含一个反向检查：把组件从原页面移到另一个结构不同的页面，观察是否仍满足预期。若只在原页面通过，样例只证明了该页面成立，没有证明组件可复用。对已有经验的团队来说，这一步常被省略，却是同一组件跨页面表现不一致时最有效的分界线。
因此，构造验收样例的重点不是增加断言数量，而是把页面提供的隐含条件显式化。条件显式化之后，组件在哪个页面正常、在哪个页面异常，都能落到可比较的证据上，而不是停留在“有时好有时坏”的观察。
