先固定组件本身的输入,再让页面环境成为唯一变量,才能判断差异来自组件还是来自页面。做法是选一个已知正常的基准页,复制出只改动一个环境因素的对照页,把两页的渲染结果、请求记录和交互结果并排核对。若差异在对照页复现,说明问题与那个环境因素相关;若不复现,则应回到基准页继续排查,而不是直接改组件代码。
同一组件在不同页面表现不同,通常落在三类原因上:组件依赖的页面级样式或脚本、组件被放置的容器结构、以及数据或权限上下文。三者的验收样例不同,取舍也不同。
如果三类原因混在一起,先做减法:把组件放到一个最小空白页,只保留必要容器和样式。最小页正常,说明组件本身可用;最小页异常,才考虑改写组件。这个动作的结果直接决定下一步是查页面还是查组件。
验收样例的价值在于可复现。要让别人按同样步骤得到同样结论,至少固定以下变量,并在样例中写明取值:
固定变量后,每个样例只允许一个变量不同。假设基准页容器宽度为 960 像素,对照页为 640 像素,其他条件一致,若组件只在 640 像素下换行错乱,则差异可归因到宽度适配,而不是数据或脚本。这个结论只说明该假设下宽度是相关因素,不能直接推断所有窄容器都会出问题。
页面表现差异容易引出多种解释,例如“组件有 bug”“页面样式污染”“数据没加载”。要区分它们,需要能核对的证据,而不是截图观感。
需要提醒的是,请求量或报错数归零不能单独证明处理正确。资源被缓存、接口被页面提前拦截、报错被统一捕获,都可能让数字消失而问题仍在。因此证据要成组看:请求正常但渲染异常,指向样式或容器;渲染正常但交互无效,指向事件绑定或权限。
三种取舍各有前提,不必强行都走一遍。
保留适用于差异只出现在个别页面,且该页面属于可调整的少数。动作是修正页面引入方式或容器结构,然后回到基准页复测。若基准页不受影响,保留组件是成本最低的选择。
改写适用于差异在多个页面重复出现,或组件依赖了不稳定的页面级样式。动作是把组件对页面的隐式依赖改为显式参数,例如把宽度、间距、数据来源变成可传入的配置。改写后需要重新跑一遍全部样例,确认没有引入新的差异。
退出适用于组件无法在目标页面稳定渲染,且改写成本高于替换成本。动作是记录已确认的失败样例,作为替换方案的验收基线。退出不是放弃排查,而是把已核对的证据留给下一个组件,避免重复踩同一个环境差异。
下面是一个假设的样例结构,用于说明如何组织信息,不代表任何具体项目结果。它把每个样例写成可独立执行的一行记录:
样例编号 | 页面 | 组件版本 | 容器宽度 | 数据状态 | 预期结果 | 实际结果 | 结论
例如,基准页在 960 像素、单条数据下预期按钮可见且可点击;对照页在 640 像素、同样数据下按钮被遮挡。两条记录并排后,差异集中在宽度,下一步就应检查组件的宽度适配规则,而不是先改数据加载逻辑。若把数据状态也改成空数据后差异消失,则说明宽度与数据存在交互影响,需要再增加一条只改数据的样例来确认。
样例写完后,至少让另一个人按记录独立执行一次。如果对方得到不同结论,说明变量没有固定全,应先补全样例再继续判断。这个复核动作的结果,决定你是继续收集证据,还是已经可以进入保留、改写或退出的决策。