个人博客建站，同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /432720c4267b.html
📄
个人博客建站，同一组件在不同页面表现不同时怎样构造验收样例
先别急着改组件，先构造能重复触发差异的验收样例：固定一组页面、一组输入和一组观察点，让同一组件在首页、文章页、归档页各跑一遍。若差异只在某一页出现，问题多半在页面传入的数据或容器样式；若每页都不同，才考虑组件自身状态或渲染顺序。缺少完整数据或权限时，仍可用本地静态样例和浏览器开发者工具完成这套动作，但不能据此断定线上所有访客都会看到同样结果。
先把差异拆成可观察的三层
同一组件表现不同，通常落在三层：数据层、容器层、组件内部状态层。验收样例要分别覆盖，而不是只截一张图。数据层看传进去的字段是否缺失或类型不同；容器层看父元素的宽度、栅格、溢出规则；组件内部状态层看它是否依赖挂载顺序、异步数据或本地存储。
一个可执行的最小动作：在本地建三个静态页面，分别模拟首页摘要、文章正文、归档列表，把同一组件嵌进去，传入三组不同但可控的数据。打开浏览器开发者工具，逐页记录组件的计算宽度、传入属性值和渲染后的 DOM 结构。如果只有归档页的宽度异常，下一步应查该页容器，而不是改组件源码。
保留、改写还是退出：三种取舍的适用前提
保留适用于差异只来自页面容器，且组件本身在三种容器下都能正常工作。此时动作是给容器补约束，例如统一最大宽度或清除浮动，然后重跑同一组样例确认差异消失。
改写适用于组件把页面假设写死在内部，例如默认自己一定在窄容器里。前提是你有源码或可覆盖的样式入口。动作是把这些假设提为可传入的选项，再用三组样例验证默认值不破坏原有页面。
退出适用于差异来自第三方组件的未公开行为，且你没有权限改它的内部实现。前提是替换成本低于持续排障成本。动作是先记录它在三个页面的失败条件，再评估是否有更简单的原生实现能覆盖同样需求。
三种取舍不是都要走一遍。多数个人博客建站场景里，先做保留加容器修正，就足以让差异收敛。
验收样例要写成可重复的步骤，而不是结论
样例的价值在于别人照着做能得到同样观察。建议每条样例包含：页面路径、传入数据、视口宽度、观察点和预期。例如假设一个卡片组件在首页显示正常、在文章页底部被压缩，样例可以写成：
- 页面：文章页底部推荐区
- 传入数据：三条标题长度不同的条目
- 视口：窄屏与宽屏各一次
- 观察点：卡片计算宽度、文字是否换行、图片是否溢出
- 预期：卡片宽度与首页一致，文字换行不撑破容器
执行后如果只有长标题那条溢出，说明差异与数据长度相关，下一步应测更多标题长度，而不是直接改全局样式。
缺少数据或权限时，哪些结论不能下
本地静态样例能证明组件在受控输入下的表现，不能证明线上真实访客看到的结果。若你没有线上日志或后台权限，就不要把本地复现的差异当成全量结论。请求量、抓取量或某项统计归零，也不能单独证明你的处理正确，它还可能来自缓存、访问路径变化或统计口径调整。
可执行的最小动作是：把本地样例的观察结果整理成一份对照记录，标明哪些页面已覆盖、哪些输入未覆盖。这份记录能帮你决定下一步是继续补样例，还是先改容器。它不能替代线上验证，但足以支撑一次有依据的取舍。
一个简短的假设例子
假设同一导航组件在首页横向排列，在文章页折成两行。你构造三组样例：首页、文章页、归档页，传入相同菜单项。结果只有文章页折行。检查发现文章页容器宽度被正文栏限制。动作是给该容器单独放宽或让导航脱离正文栏，重跑样例后折行消失。若放宽后正文阅读宽度受影响，则改为在文章页使用简化导航。这个例子的数字和页面均为假设，只用于说明比较方法：先固定输入，再逐层排除，最后按影响面决定保留、改写还是退出。
