网站开发中：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b9fbe2803bc2.html
📄
网站开发中：同一组件在不同页面表现不同时怎样构造验收样例
先把“表现不同”拆成两类：一类是组件在页面里被外层布局或数据上下文改变了，另一类是组件自身状态在特定交互后才出现。验收样例要覆盖这两类，而不是只截一个看起来正常的页面。做法是固定组件版本，分别构造“最小宿主页面”和“真实页面切片”两组样例，前者用于定位组件本身，后者用于确认页面集成后的结果。
先判断差异来自组件还是来自宿主页面
同一个组件在不同页面表现不同，常见原因不是组件代码有两套，而是宿主环境不同：容器宽度、父级样式、传入数据量、路由参数、权限状态、异步加载顺序。判断依据可以这样取：把组件放进一个只有必要依赖的最小页面，如果表现恢复正常，差异大概率来自宿主；如果最小页面里仍然不同，差异更可能在组件内部或依赖版本。
这一步的实际动作是建立最小宿主页面，并记录三个信息：组件输入数据、外层容器约束、页面加载完成时组件所处的状态。这个动作的结果决定下一步：若最小宿主正常，就回到真实页面逐项还原宿主条件；若最小宿主异常，就先收窄组件版本和依赖，而不是继续改页面样式。
验收样例分两组：最小宿主与真实页面切片
两组样例的用途不同，不要混在一张清单里。
- 最小宿主样例：只保留组件运行必需的父容器、数据源和样式入口。用于回答“组件自身是否稳定”。适合在组件升级、依赖变更、样式重构后先跑。
- 真实页面切片：从实际页面中截取组件所在的区块，保留真实父级结构、真实数据形态和相邻组件。用于回答“集成后是否仍然成立”。适合在页面模板调整、布局系统更换、内容量变化后跑。
选择依据是变更范围：只动组件包，先跑最小宿主；动页面骨架或全局样式，两组都要跑。例外是组件依赖页面级路由或全局状态时，最小宿主必须补上这些依赖的桩，否则最小宿主会给出误导性的通过结果。
把“表现不同”写成可核对的断言
验收样例不能只写“显示正常”。要把差异描述成可观察的断言，至少包含四项：触发条件、观察位置、预期结果、失败时的判定。例如假设某列表组件在长内容页面出现高度塌陷，样例可以写成：
- 触发条件：容器宽度设为页面主栏宽度，传入 20 条以上数据。
- 观察位置：组件外层容器的高度与相邻区块的间距。
- 预期结果：容器高度随内容增长，相邻区块不被覆盖。
- 失败判定：容器高度小于内容高度，或相邻区块出现重叠。
这里使用假设数字只是为了说明比较方法，不代表任何真实项目的阈值。真正可用的样例应当来自你当前页面的实际约束，而不是照搬这里的数值。
执行顺序与结果如何影响下一步
建议按“先最小宿主、后真实切片、再跨页面抽样”的顺序执行。最小宿主通过而真实切片失败，说明问题在集成层，下一步应检查父级样式、数据形态和加载顺序；最小宿主失败，说明问题在组件或依赖，下一步应锁定版本并对比改动前后的输入输出；两组都通过但用户仍反馈不同，说明样例遗漏了触发条件，下一步应补充交互路径或状态组合，而不是直接判定组件无问题。
跨页面抽样时，至少选两个宿主差异明显的页面：一个内容量小、布局简单，一个内容量大、嵌套层级深。若两者结果一致，可以降低该组件的回归频率；若不一致，应把差异页面加入固定样例集，并在组件变更时优先跑这一组。
容易忽略的例外与边界
有些差异无法通过静态样例复现，例如只在慢速网络、权限切换或异步数据返回顺序不同时出现。这类情况需要把等待状态和错误状态也纳入样例，而不是只验收成功状态。另一个边界是组件依赖第三方服务时，样例应使用可控的模拟响应，避免把外部波动误判为组件缺陷。验收样例的目标是让不同角色对同一事实有可核对的依据，因此样例必须能重复执行，并且失败时能指向具体条件，而不是停留在主观描述。
