自助建站系统：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e639bc92b5f.html
📄
自助建站系统：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要试图构造一个“万能样例”去覆盖所有页面，而要把组件拆成“固定输入”和“页面环境”两层，用同一份输入分别投放到表现不同的页面上，记录差异来自哪一层。验收样例的目标不是证明组件正常，而是让差异可复现、可归因。如果差异只在某一类页面出现，就为那一类页面单独写样例；如果差异随页面数量增加而扩散，说明问题在环境层，应优先固定环境而不是继续加样例。
先判断差异出在哪一层，再决定样例保留还是重写
同一组件在列表页正常、在详情页错位，常见原因有三类：容器宽度与内边距不同、同级元素数量或长度不同、页面加载顺序不同。这三类对应不同的处理方式。
- 容器差异：组件本身没问题，是父级给了不同的宽度约束。此时保留原样例、只补一条“窄容器”样例即可。
- 内容差异：详情页里标题更长、图片更多，把组件撑开。样例要改写，输入数据必须包含长文本和缺图两种情况。
- 加载顺序差异：组件依赖的脚本或样式在部分页面晚到。样例要加入延迟加载的假设，而不是只测静态渲染结果。
可用的区分证据：把同一段输入分别放进两类页面，若只在其中一类出错，锁定环境层；若两类都出错但程度不同，锁定输入层。这个判断直接决定下一步是改页面模板还是改组件配置。
两种做法取舍：为每类页面各写一份样例，还是只维护一份基准样例
做法一：为每类页面各写一份样例。适用前提是页面类型稳定、数量有限，且差异确实由页面结构造成。代价是样例数量随页面类型增长，后续组件改动要同步多处，维护成本上升。它适合详情页、列表页、首页这类结构差异明显且长期不变的场景。
做法二：只维护一份基准样例，把页面差异抽成参数。适用前提是差异可以用少数几个变量描述，比如容器宽度、是否含侧栏、内容长度档位。代价是前期要把变量定义清楚，否则参数会越加越多，最后退化成做法一。
选择条件可以这样判断：如果差异原因能被两三个变量解释，选做法二；如果每类页面的差异原因各不相同，选做法一。假设一个站点只有“带侧栏”和“不带侧栏”两种布局，那么用宽度参数就能覆盖，不必写两份样例；如果详情页还额外受评论模块影响，参数就描述不了，此时为详情页单独保留一份样例更实际。
构造样例时的实际动作与结果如何影响下一步
具体动作：先固定一份输入数据，包含最短标题、最长标题、无图、多图四种情况；再把它分别投放到表现不同的两个页面；最后逐项记录组件的位置、尺寸和可见状态。记录时只写可观察结果，不写“看起来正常”这类判断。
结果会影响下一步：如果两个页面只在“最长标题”下出现差异，下一步应改组件对长文本的处理，而不是改页面；如果差异在四种输入下都存在，下一步应先统一页面容器约束，再回头测组件。这个顺序能避免在错误的一层反复调整。
需要提醒的是，某次抓取量或请求量归零，不能单独证明组件或页面处理正确，也可能只是缓存、访问路径变化或统计口径调整造成的。验收样例看的是可复现的页面表现，不是单一指标的升降。
退出条件：什么时候该停止加样例
当新增样例不再产生新的差异类型，只是重复已有结论时，就该停止扩充。继续加样例的代价是维护负担，而不是更高的可信度。此时更有效的动作是把已确认的差异写成固定检查项，纳入组件改动后的回归范围。
反过来，如果每加一个页面就冒出一类新差异，说明组件对环境的依赖过强，应优先考虑替换或收敛该组件的使用范围，而不是无限追加样例。这个判断依据是差异类型的增长速度，不是页面总数。
把上面的取舍落到一句话：差异能被少数变量解释就参数化，不能被解释就按页面类型分别样例，样例不再产生新类型时就退出扩充，转为回归检查。按这个顺序执行，验收样例才会随站点演进而保持可用，而不是变成一份没人维护的旧清单。
