网站设计加SEO，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cd60ca0f9ca9.html
📄
网站设计加SEO，同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要用“某个组件在首页正常”当作全站验收通过的依据，而要把组件放回它实际出现的页面类型里，各取一个最小样例，分别记录渲染结果、可抓取文本和交互后的状态。假设有一个商品筛选组件：列表页正常展开，详情页的“相关推荐”里却只显示空白占位；这时要验收的不是组件本身，而是“同一组件在不同容器、不同数据源、不同加载顺序下”是否都成立。
先分清是组件问题还是页面环境问题
同一组件表现不同，常见原因不在组件代码，而在页面给它的上下文不同。构造验收样例前，先列出四个变量：容器宽度与父级样式、数据来源与字段完整性、渲染时机（服务端输出还是客户端挂载）、同页是否存在多个实例。只要其中一个不同，就不该把两个页面的结果互相套用。
判断依据可以这样区分：
- 若换个页面就空白，但同页单独打开组件正常，优先怀疑父级样式或挂载时机。
- 若文本能选中却不在初始HTML里，说明内容依赖客户端渲染，要单独验收可抓取文本。
- 若只有列表页第一屏正常、滚动后异常，记录的是分页或懒加载边界，不是组件缺陷。
- 若同一页面出现两个实例只有一个异常，检查ID重复、事件绑定或全局状态污染。
这一步的实际动作是：为每个变量各建一个最小页面样例，只改一个变量，其余保持一致。结果会直接决定下一步——是修组件，还是修页面容器，还是把该页面排除出“可复用组件”的适用范围。
用假设情境走一遍验收样例的构造
假设某站点把“面包屑”做成通用组件，首页不出现，栏目页和文章页都调用它。栏目页显示正常，文章页却只显示最后一级。先不要改代码，而是按下面顺序构造样例。
- 取三个页面：栏目页、文章页、一个带多级路径的专题页，作为最小样例集。
- 对每个页面记录三样东西：初始HTML里是否有完整层级、浏览器渲染后是否一致、点击每一级是否能到达对应位置。
- 只调整数据输入，不改组件：给文章页补上完整层级字段，再看输出是否恢复。
- 若补数据后仍异常，再固定数据、改容器，检查父级是否截断或隐藏了中间层级。
这个顺序的价值在于：它把“组件坏了”与“页面没给够数据”分开。假设补数据后文章页恢复正常，那么结论是该组件对数据完整性有强依赖，验收样例必须包含“字段缺失”这一负例，而不能只测理想数据。若补数据无效、换容器有效，则结论是样式作用域问题，验收重点转向容器约束。
验收样例要覆盖哪些页面类型，不能只挑正常的
规模化后出现例外，通常是因为样例只覆盖了“最配合”的页面。构造样例时，至少按页面类型分组，而不是按组件分组。可以按下面的维度各取一个代表页：
- 内容型页面：正文长、侧栏多、同页组件实例多。
- 列表型页面：数据条数可变、存在分页或筛选。
- 详情型页面：字段可能缺失、层级可能不完整。
- 聚合型页面：多个数据源拼接，加载顺序不一致。
每组记录同一组指标：初始HTML中的文本、渲染后的可见文本、交互后的状态、以及该状态是否随刷新变化。这里要说明适用条件：如果站点主要靠客户端渲染，那么“初始HTML有文本”这一项可能本就不成立，此时应把验收重点放在渲染后的一致性和可访问性上，而不是强行要求服务端输出。边界写清楚，样例才不会被误用成全站标准。
把样例结果转成可执行的验收判定
样例跑完后，不要停留在“看起来正常”。把每个样例的预期写成可判定的句子，例如“文章页面包屑在初始HTML中包含全部层级，渲染后层级数量不变，点击末级返回当前页”。判定要能回答是或否，而不是“基本可用”。
当某个样例不通过时，先确认它属于哪一类：数据缺失、容器冲突、渲染时机、还是多实例干扰。不同类别对应不同动作——补数据、改容器、调整加载顺序、隔离实例。动作执行后，只重跑受影响的样例组，而不是全站重测。这样做的结果是：你能明确说出该组件在哪些页面类型下成立、哪些不成立，而不是用一句“已验收”掩盖例外。
最后要接受一个现实：同一组件在不同页面表现不同，往往不是缺陷，而是适用边界。验收样例的作用，是把这条边界写出来，让后续页面在复用前就知道自己是否落在边界内。
