新手建站教程：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad4a0fd00308.html
📄
新手建站教程：同一组件在不同页面表现不同时怎样构造验收样例
先把“组件坏了”与“组件被页面环境改变了”分开。构造验收样例时，不要只截取异常页面，而要把同一组件放到至少两个真实页面上下文中，记录输入、容器、样式来源和交互结果；如果差异只在某个页面出现，优先检查该页面的容器宽度、层叠样式、脚本加载顺序和内容结构，而不是先改组件本身。
先判断是组件问题还是页面环境问题
同一组件在不同页面表现不同，常见有两种解释。第一种是组件自身在特定输入下不稳定，例如数据为空、字段缺失或状态切换时没有兜底。第二种是页面环境改变了组件的外部条件，例如父容器宽度不同、页面加载了额外样式、同一脚本被重复引入，或内容区域先于组件渲染完成。
这两种解释不能靠“换个页面再试一次”区分。更有效的证据是控制变量：固定数据、固定视口、固定交互步骤，只改变页面环境中的一项。若只改容器宽度就复现差异，环境因素更可信；若在任何容器中都随数据变化而异常，组件自身逻辑更值得先查。
把验收样例写成可重复的输入与预期
验收样例要能让他人复现，至少包含页面路径、组件位置、输入数据、操作步骤、观察结果和预期结果。不要只写“首页正常、详情页错位”，而应写成：在详情页把内容区宽度设为与首页一致后，错位是否消失；在首页把同一组数据替换为空值后，是否出现相同异常。
可以按下面的顺序组织一组最小样例：
- 选两个使用同一组件的页面，一个表现正常，一个表现异常。
- 为两个页面准备相同的数据和相同的操作步骤。
- 先固定视口与浏览器缩放，再分别记录组件外框尺寸、可见文本和交互结果。
- 只改变一个环境因素，例如容器宽度、样式引入或脚本顺序，再记录结果。
- 把“改变哪一项后结果如何变化”写入验收结论，而不是只写通过或失败。
这样做的实际作用是缩小下一步动作。若改变容器宽度后差异消失，下一步应检查页面布局约束和样式作用域；若改变数据后差异出现，下一步应检查组件的空值处理和状态分支。
用一组对照样例区分两种原因
假设一个列表组件在栏目页显示正常，在搜索页出现按钮错位。可以构造三组对照，而不是直接修改组件样式。第一组：两个页面使用相同数据，只保持各自原样，记录差异。第二组：把搜索页的容器宽度临时调整为与栏目页一致，其他不变。第三组：把栏目页的数据替换为搜索页的数据，其他不变。
如果第二组差异消失，说明页面容器或布局约束参与了问题；如果第三组在栏目页复现异常，说明数据形态或空值处理更可疑。这里的数字和页面名称只是假设示例，重点是比较方法：每次只改一个条件，并保留修改前后的观察记录。验收样例的价值不在于证明谁对，而在于让下一次修改有明确方向。
旧页面退出时，验收样例要保留仍然有效的部分
当旧内容、旧系统或旧合作关系需要退出时，同一组件往往同时出现在待保留页面和待下线页面。此时不要把所有异常都归为“旧页面问题”。更稳妥的做法是：先标记哪些页面仍在使用该组件，再为保留页面建立基线样例，为退出页面建立只读样例。
基线样例用于确认保留页面在改动后仍能正常工作；只读样例用于记录退出前的表现，避免误把历史差异当成新缺陷。若退出页面不再维护，验收重点应放在保留页面的数据迁移、链接指向和组件依赖是否完整，而不是要求退出页面继续适配新环境。
记录结论时避免把现象当成原因
“搜索页按钮错位”是现象，不是原因；“组件有 bug”也是结论，不是证据。验收记录应写明：在什么页面、什么数据、什么视口、什么操作下，观察到什么结果；改变哪一个条件后，结果如何变化。若请求量、抓取量或某项统计归零，也不能单独证明处理正确，因为缓存、入口变更、权限调整或统计口径变化都可能产生同样现象。
最终可执行的下一步通常只有两类：若差异随页面环境变化，先修页面约束和加载顺序；若差异随数据或交互变化，先修组件的输入处理和状态分支。把这两类结论分开记录，后续修改才不会在页面与组件之间反复摇摆。
