网站设计规范，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /162ba7dbe023.html
📄
网站设计规范，同一组件在不同页面表现不同时怎样构造验收样例
先给结论：不要把“组件在首页正常、在列表页异常”当成一个整体问题去验收，而要把组件拆成结构、状态、数据量、容器约束四类变量，为每类变量各写一条可复现的最小样例。缺少完整数据或权限时，先用静态占位和手工改参构造样例，仍然能区分“组件本身有问题”还是“页面环境把它带偏了”。这类样例只能证明差异在哪个变量上出现，不能直接推出全站所有页面都已修复。
先分清两种解释：组件缺陷，还是环境差异
同一组件表现不同，通常只有两个方向：
- 组件自身状态覆盖不全。比如按钮组件只写了默认态和悬停态，没写禁用态、加载态、空数据态；到了需要这些状态的页面就露馅。
- 页面环境改变了组件的前提。父容器宽度、栅格列数、字体继承、外边距折叠、层级堆叠，任何一项不同，都可能让同一份组件代码渲染出不同结果。
这两种解释的修复动作完全不同：前者改组件，后者改页面容器或使用约定。验收样例必须先能区分它们，否则改完一处，另一处照旧。
用一组可区分原因的证据来定位
能区分两种解释的证据，不是截图对比，而是控制变量后的对照样例。建议按下面的顺序构造：
- 同容器、换页面数据。把组件放进一个固定宽度的测试容器，只替换内容长度和状态。若表现随数据变化，偏向状态覆盖问题。
- 同数据、换容器。保持内容不变，只改父容器宽度、内边距和栅格列数。若表现随容器变化，偏向环境差异。
- 同数据、同容器、换引入方式。分别用全局样式和局部作用域引入，观察是否出现差异，用来排查样式泄漏或继承。
这三步做完，你手上就有了一组能指向原因的样例，而不是一堆“看起来不对”的页面。
缺少数据或权限时的最小动作
没有真实接口、没有后台权限，仍然可以执行最小动作：在本地或测试环境建一个临时页面，用静态数组模拟不同长度、不同状态的数据，把组件按上述对照条件各渲染一次。动作的结果是：你能拿到“哪种变量触发异常”的记录，下一步就能决定是给组件补状态样式，还是给页面加容器约束。
需要说明的是，静态样例通过，不能推出真实数据下也通过；真实数据里的极端长度、空值、超长无空格字符串，仍可能触发新问题。所以样例只是缩小排查范围，不是最终验收结论。
把样例写成可执行的验收条目
样例要能被别人重跑，必须写清前置条件。可以按这个结构写：
- 组件名与使用位置（哪个页面、哪个区域）。
- 固定条件：容器宽度、栅格列数、字体基准。
- 变化条件：数据长度、状态（默认/禁用/加载/空）。
- 预期表现：对齐、换行、截断、间距中哪一项应保持一致。
- 判定方式：目视检查还是量取具体尺寸。
假设某卡片组件在首页两列布局下正常，在三列列表页出现文字溢出。可以构造一条样例：容器宽度固定为三列时的实际值，内容用一段无空格长字符串，预期是截断而非撑破容器。若截断生效，说明问题在页面容器约束；若仍溢出，说明组件内部缺少溢出处理。这个判断直接决定下一步改哪一层。
写样例时容易踩的坑
第一，把“某一页正常”当成组件已验收，忽略了其他页面用的是不同容器。第二，只记录现象不记录变量，别人无法复现。第三，用真实数据当唯一依据，数据一变结论就失效。第四，把一次通过当成长期结论，后续容器或样式调整后需要重跑。
验收样例的价值不在于数量多，而在于每条都能回答“如果它失败，我该改组件还是改页面”。做到这一点，同一组件在不同页面的表现差异就不再是玄学，而是一条条可追踪、可复现、可决定下一步动作的记录。
