网站制作中：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /afc5b823ef28.html
📄
网站制作中：同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要试图用“统一组件就应该处处一致”来验收，而要把组件拆成结构、样式、数据、交互四层，为每一层分别设定可判定的样例。当同一组件在不同页面表现不同，通常不是组件坏了，而是它在不同上下文里接收了不同的输入。验收样例的任务，是固定这些输入并记录预期输出，而不是追求一个放之四海皆准的截图。
先分清两种“表现不同”
假设你做了一个卡片组件，在列表页显示正常，在详情页侧栏却出现文字溢出、图片比例失真。此时有两种合理解释：
- 上下文差异导致的正常变化。侧栏容器更窄，组件按自身响应式规则收窄，文字换行增多，这是设计允许的行为。
- 组件对外部环境存在隐式依赖。组件内部用了全局字号、继承的宽度或某个父级类名，换个页面就失控，这是缺陷。
两者外观可能一模一样，但处理方式完全相反。前者只需补充验收条件，后者必须修改组件。若不加区分就统一改样式，很可能把本来正确的页面改坏。
用一组证据区分是“正常变化”还是“隐式依赖”
能区分这两种解释的证据，不是再看几眼截图，而是做变量隔离。具体动作：把该组件单独放进一个最小容器，容器只设固定宽度，不引入页面级样式，然后逐步加回页面环境。
- 先在裸容器中渲染，记录结构、字号、间距、换行位置。
- 再套上目标页面的父级容器，保持其他条件不变，观察哪些属性变了。
- 若变化只来自容器宽度，属于正常响应；若字号、颜色、圆角等与宽度无关的属性也变了，说明组件读取了外部继承值或全局选择器。
这一步的结果直接决定下一步：正常响应就把容器宽度写进验收条件；隐式依赖就回到组件内部，把继承值改为显式传入的参数。若不先做这步，后续所有验收样例都建立在错误前提上。
构造验收样例的四个层次
针对同一组件的多页面表现，样例应覆盖以下层次，每层给出明确输入与预期：
- 结构层：固定数据条数、字段缺失、超长文本三种输入，预期 DOM 层级和可访问名称不变。
- 样式层：固定容器宽度档位（如窄、中、宽三档），预期换行、截断或省略行为符合约定，而不是“看起来差不多”。
- 数据层：固定空值、单条、多条三种数据，预期占位内容、数量显示和排序规则一致。
- 交互层：固定悬停、聚焦、禁用三种状态，预期反馈方式在各页面相同。
每层样例都应写明适用条件。例如“窄容器下允许文字换行但不允许溢出容器边界”，而不是笼统写“显示正常”。
一个注明假设的短例子
假设某组件在 A 页面宽度为 320px 时正常，在 B 页面宽度为 280px 时文字溢出。若验收样例只写了“在 A 页面通过”，那么 B 页面的失败无法判定是组件问题还是样例缺失。补上“最小支持宽度 280px”这一条件后，溢出即判定为缺陷，需要修改组件的最小宽度处理逻辑。这个假设说明：验收样例的价值不在于记录当前表现，而在于提前声明组件承诺支持的范围。范围之外的差异不算失败，范围之内的差异必须可复现、可判定。
让样例可复用的两个实际动作
第一，把组件样例与页面样例分开存放。组件样例只验证组件自身在固定输入下的输出；页面样例验证组件与页面容器的组合。这样当页面改版时，只需重跑页面样例，组件样例仍然有效。
第二，为每个样例标注“依赖条件”。依赖条件包括容器宽度、父级字号、数据形态和状态。验收时若依赖条件未满足，该样例结果不参与判定。这一步能避免把环境差异误判为组件回归，也能避免为了通过样例而给组件堆叠不必要的兼容代码。
当同一组件在不同页面表现不同时，先隔离变量，再按层次写样例，最后用依赖条件约束判定范围。这样得到的验收结果才能指向明确的修改动作，而不是停留在“再调调看”。
