优化建站：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /91b09d0ad565.html
📄
优化建站：同一组件在不同页面表现不同时怎样构造验收样例
先判断差异来自组件自身还是页面上下文：如果组件在多个页面只有样式或数据不同，验收样例就按“组件契约 + 页面注入条件”两层写；如果差异已经改变交互结果或数据结构，验收样例必须按页面单独构造，不能共用一份。选择依据不是哪个做法更省事，而是同一份失败样例能否稳定复现问题。
两种条件下的不同选择
条件一：组件代码相同，差异只出现在外层容器宽度、字体继承、语言方向或传入数据上。此时应保留一份组件级验收样例，再为每个页面补一条上下文样例。组件级样例验证默认行为，上下文样例验证覆盖后是否仍成立。代价是样例数量增加，但能避免把页面问题误判成组件缺陷。
条件二：组件在某个页面被替换了实现、增加了分支逻辑，或接收的数据结构不同。此时不应追求共用样例，而应为该页面单独构造验收样例，并明确它不再覆盖组件默认行为。代价是维护两份甚至多份样例，但换来的是失败可定位：组件级失败说明契约被破坏，页面级失败说明接入方式有问题。
判断动作可以先做一次最小对照：把两个页面的组件放入相同容器和相同数据，如果表现仍然不同，就归入条件二；如果表现趋同，就归入条件一。这个动作的结果直接决定下一步是补上下文样例还是拆出独立样例。
验收样例要写到什么颗粒度
样例至少包含四类信息：输入条件、触发动作、可观察结果、通过条件。输入条件写清页面路径假设、容器宽度、数据来源和语言；触发动作写清加载、点击、滚动或键盘操作；可观察结果写清哪个区域发生什么变化；通过条件写成可判定的是或否，而不是“看起来正常”。
例如，假设一个筛选组件在列表页收起、在详情页展开，差异来自页面传入的初始状态不同。组件级样例可以验证默认收起；列表页样例验证传入收起后筛选结果仍可读取；详情页样例验证传入展开后焦点顺序和关闭动作正确。这里的所有数字和路径都是假设，用来说明比较方法，不代表真实项目。
如果只写“组件显示正确”，后续无法区分是组件回归还是页面接入回归。把通过条件落到具体区域、具体状态和具体操作后，失败样例才能反向指向修改位置。
实施动作与结果如何影响下一步
第一步，为同一组件建立一份基线样例，记录它在默认条件下的可观察结果。第二步，为目标页面各建一份差异样例，只记录与基线不同的输入和结果。第三步，运行基线样例；如果基线失败，先修组件，不继续看页面样例。第四步，基线通过后运行页面样例；如果页面样例失败，检查页面传入条件、容器样式和初始化顺序。
这个顺序会直接影响下一步：基线失败时补页面样例没有意义，因为问题在组件契约；基线通过而页面失败时，继续改组件可能引入新的默认行为回归，应该先核对页面注入条件。实际动作的结果不是“跑完就算”，而是决定修改范围停在组件层还是页面层。
例外与适用条件
有些差异无法用静态样例稳定复现，例如依赖实时数据、用户权限、网络状态或第三方嵌入内容。这类情况应把验收样例写成条件矩阵：明确哪些条件必须固定，哪些条件允许变化，变化时观察哪个降级结果。若条件无法固定，样例只能作为探索记录，不能作为通过依据。
还有一种例外是组件本身处于迁移期，同一时间存在新旧两套实现。此时验收样例要按实现版本分开，不能把两套结果混在一份通过条件里。等迁移结束后再合并样例，合并前先确认旧实现的页面已经不再引用。
最后，不要把请求量、抓取量或某个统计归零当作验收通过的证据。这些现象可能来自缓存、采集延迟、权限变化或页面未被触发，不能单独证明组件处理正确。验收仍应回到可观察结果和通过条件本身。
