马鞍山建站：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1f20a746a5aa.html
📄
马鞍山建站：同一组件在不同页面表现不同时怎样构造验收样例
先给有条件的结论：当同一组件在列表页、详情页或弹窗里表现不一致时，验收样例不应只截一张“正常页面”的图，而要把组件放回它实际出现的每个容器里，用同一组输入分别验证。只有确认差异来自容器约束、数据形态或加载顺序，才谈得上修哪一层。若差异只在某个页面出现且换数据后消失，那更可能是数据问题而不是组件缺陷。
先分清三种差异来源，再决定样例怎么造
同一组件表现不同，常见原因可以归成三类，对应的验收样例也不同。
- 容器约束差异：父级宽度、内边距、定位方式不同。样例要固定视口宽度，把组件分别放进窄栏、主栏和全宽容器，记录它是否溢出、换行或截断。
- 数据形态差异：标题长度、图片比例、字段缺失。样例要准备短文本、超长文本、无图、多图这几组输入，而不是只用一条最规整的数据。
- 加载与依赖差异：组件在首屏直出，或在异步请求后才渲染。样例要覆盖“数据未到”“数据到达”“请求失败”三个状态。
这三类里，只有第一类属于组件自身需要改的情况。第二类通常改数据校验或兜底样式，第三类改的是调用时机。如果把三类混在一张验收单里，结论会互相干扰。
验收样例的最小结构：固定输入、固定容器、固定观察项
一份能复现问题的样例，至少要写清三件事，缺一件就无法判断是组件的问题还是环境的问题。
- 输入：用哪条数据、字段值是什么、是否为空。可以用占位数据，但要注明它是假设样例，不是真实内容。
- 容器：组件被放在哪个页面区域，该区域的宽度范围和定位方式。
- 观察项：看什么。例如高度是否超出容器、文字是否被裁掉、点击区域是否仍然可点。
一个简化的假设例子：某卡片组件在详情页正常，在侧栏里高度撑破容器。样例写成“输入：标题 40 字、无配图；容器：侧栏，宽度约 300 像素；观察项：卡片底部是否超出侧栏边界”。换一条 10 字标题再跑一次，如果不再溢出，说明触发条件是文本长度，而不是侧栏本身。
让结论失效的反例：差异只在单个页面出现
如果同一组件只在某一个页面异常，其他页面用同样容器和同样数据都正常，那“组件有缺陷”这个结论就不成立。此时更合理的解释是：那个页面额外加载了覆盖样式、引入了第二个同名类，或者它的数据在渲染前被别的脚本改过。
判断方法很直接：把该页面的组件单独复制到一个空白测试页，只保留组件自身依赖。如果异常消失，问题在页面环境；如果异常还在，问题才回到组件。这个动作的结果会决定下一步是查页面样式冲突，还是回到组件内部改结构。
把验收结果转成下一步动作
跑完样例后，按下面顺序处理，避免反复返工：
- 差异随容器变化 → 改组件的宽度自适应或换行规则，并补一条窄容器样例。
- 差异随数据变化 → 加字段长度限制或兜底展示，并补长文本、空值样例。
- 差异只在单页出现 → 先查该页的样式覆盖与脚本改动，不要直接改公共组件。
需要提醒的是，某个页面组件“看起来正常”不能单独证明组件没问题，也可能是该页数据恰好规整。反过来，某个页面异常也不能单独证明组件坏了。验收样例的价值在于把变量固定下来，让每次只变一个条件。
适用条件与边界
这套做法适合组件被复用在多个容器、且页面样式存在局部覆盖的情况。如果整个站点只有一处使用该组件，且没有独立样式覆盖，构造多容器样例的收益有限，直接在该页验证即可。另外，若差异来自浏览器版本或设备差异，应另建一组按设备划分的样例，不要和容器、数据两类混在一起。
下一步动作建议是：挑出表现最不一致的那一个组件，按“输入、容器、观察项”三项写出三条样例，先跑最窄容器加最长文本这一组，根据结果再决定是改组件、改数据还是查页面环境。
