先给结论:不要急着改组件,也不要直接把它判为“坏掉”。应当先构造一组最小对照样例,把页面级差异复现出来,再决定是保留组件、改写组件,还是让某个页面退出该组件。验收样例的目标不是证明组件对或错,而是找出它在哪些页面条件下成立、在哪些条件下失效。
同一组件在不同页面表现不同,常见原因并不在组件本身,而在页面提供的上下文。构造样例前,先列出可能变化的页面条件:容器宽度、外层栅格、继承的字体与行高、相邻模块的高度、内容长度、图片比例、脚本加载顺序。把其中一项或几项固定下来,再逐项放开,观察表现是否随之改变。
一个可用的判断方法是:如果同一组件在内容长度相近、容器宽度相近的两个页面上表现一致,只在某个特殊页面上异常,那么优先怀疑该页面的局部条件,而不是组件。反之,如果多个页面都出现同类偏差,只是程度不同,则更可能是组件自身的默认假设过窄。
这一步的产出不是结论,而是一份条件清单。清单越具体,后面的样例越省事。
不要拿线上整页做试验,那样变量太多。更稳妥的做法是新建一个仅用于验收的静态页面,把同一组件按不同条件重复放置,形成可对照的一组样例。假设某组件在列表页正常、在详情页错位,可以这样组织:
四个样例两两对照,就能分离出“宽度导致”还是“内容长度导致”。如果 A 与 C 表现一致、B 与 D 表现一致,说明主因是内容长度;如果 A 与 D 一致、B 与 C 一致,说明主因是容器宽度。这个结论直接决定下一步动作。
样例里还应写清假设:使用的字体、基准字号、是否加载了外部样式。这些前提不写下来,换一个人复现时结论就会漂移。
当样例显示组件在容器宽度和内容长度都落入某个区间时表现稳定,就可以保留组件,同时在使用说明里写明这个区间。适合的场景是:异常页面数量少,且这些页面的内容本身可以调整到区间内。动作是把区间写成验收项,例如“容器宽度不小于某值、正文不超过某长度时使用该组件”。结果如何影响下一步:如果后续新页面都能满足这个区间,就不必动组件代码;一旦出现无法满足的页面,就需要重新评估。
当样例显示多个页面都因同一条件失效,且这些页面的内容长度、容器宽度无法统一时,改写组件更划算。改写方向通常是去掉对固定高度、固定宽度或固定行数的依赖,让内部元素按内容自适应。适用前提是:组件被多处复用,改动收益大于逐个页面绕开的成本。动作是先改一处,再用同一组样例复测;如果四个样例表现一致,说明改写有效,可以推广;如果只改善了其中两个,说明还有未识别的条件变量。
当异常只集中在一个页面,且该页面的内容形态与组件设计假设差异很大时,退出比改写更省成本。适用前提是:这个页面的功能目标与其它页面不同,强行统一反而损害可读性或操作效率。动作是为该页面换用更合适的呈现方式,并在验收记录里注明“此页面不适用该组件”。结果如何影响下一步:需要确认退出后该页面的功能验收项仍然完整,不能因为换了组件就漏掉原有要求。
样例本身也要能验收。每条至少写清三件事:前提条件、操作步骤、可观察的预期结果。避免写“显示正常”这类无法判断的表述,改成可观察的特征,例如“标题与正文左边缘对齐”“按钮不被容器裁切”“长文本换行后不覆盖相邻元素”。
如果同一组件要跨多个页面使用,建议把样例按条件分组,而不是按页面分组。按页面分组容易掩盖真正的变量;按条件分组,任何新页面都能映射到某一组样例上,判断它是否落在已验证的范围内。
需要提醒的是,某些表现差异可能来自缓存、资源加载失败或临时网络状态,而不一定是组件或页面条件问题。复测时应先排除这些解释,再下结论;一次异常不足以证明组件在该条件下必然失效。
构造样例的最终目的,是让“保留、改写、退出”这三个动作有依据。样例支持保留时,就把适用条件写进验收项;样例支持改写时,就用同一组样例验证改写是否真的消除了差异;样例支持退出时,就明确记录哪个页面、在什么条件下不再使用该组件。这样处理之后,同一组件在不同页面的表现差异不再是一个反复出现的困扰,而是一个有边界、有记录、可复测的已知条件。