页面刚开始搭出来的时候，最容易让人产生一种错觉：只要卡片能显示，筛选能响应，页面看起来就差不多完成了。那时的数据是样例数据，数量少，字段规整，图片和视频也都经过了方便展示的处理。很多问题不会在这个阶段出现，甚至连问题的形状都还没有形成。
这次接入真实工程、真实成片和真实图片后，页面一下出现了12个工程、29条成片和30张图片。数字变多本身不是难点，难点是原来被样例数据遮住的差异同时露了出来：封面裁切丢内容，技术标签挤在一起，手机上的卡片太窄，加载失败后还不能重新尝试。页面不是从“没有数据”变成“有数据”这么简单，而是从一个视觉壳子进入了真实使用状态。
真实数据接入不是验收的最后一步，而是重新建立验收问题的起点。
样例数据通过，不等于真实页面通过
我一开始很容易沿用前面的判断：接口返回了内容，页面也出现了卡片，说明接入已经成功。后来我发现，这个判断只证明了最浅的一层。它证明“数据能到达页面”，却没有证明“数据到达之后仍然能被人正确理解和使用”。
样例数据往往太友好了。标题长度适中，标签数量有限，图片比例统一，视频地址也通常是可以直接播放的。真实数据则会把边界推到页面面前。一个封面可能在裁切后丢掉主体，一组技术标签可能因为文字长度不同而粘在一起，一张手机卡片可能因为同时容纳太多信息而失去可读性。数据结构没报错，不代表呈现结果没有错。
如果只验证接口返回非空，后果是问题会被推迟到真正使用时才暴露。那时用户看到的不是“接入还需要验证”，而是一个看似完成、实际难用的页面。修复成本也会变高，因为大家已经把数据接入当作完成，后续只能围绕视觉缺陷临时打补丁。
这件事让我重新意识到，验收对象会随着系统状态变化。样例数据阶段验收的是布局骨架和交互方向；真实数据阶段验收的是内容在各种形状下是否仍然成立。两者有关，但不能互相替代。
先验数量和字段，再看内容是否完整
真实接入以后，我先把检查拆成两层。第一层不是看页面漂不漂亮，而是核对页面应该出现多少内容，以及每种内容带有哪些字段。第5轮的结果是12个工程、29条成片和30张图片，这个数字是后面抽查的基线。数量少了，可能是筛选或加载出了问题；数量多了，也可能是重复映射或状态没有清理。
字段检查同样重要。一个卡片能出现，不等于它的标题、类型、封面、媒体地址和状态都被正确使用。字段缺失时，页面可能用空白撑出一块区域，也可能把内部标识直接暴露出来。真实数据验收不能只问“有没有卡片”，还要问“卡片里的每个判断依据是不是来自正确字段”。
我选择先做数量与字段基线，是因为它能把后面的视觉问题和数据问题分开。否则看到一张封面显示不全时，很容易误以为只是样式问题，实际可能是映射错了资源。先确认页面拿到了什么，再判断它怎样显示，排查路径会短很多。
图片和视频必须按真实终态验收
接下来才是媒体检查。图片不能只看缩略图有没有临时画面，视频也不能只看播放器控件有没有出现。真实媒体的验收要落到“能否被实际使用”：图片主体是否完整，比例变化后有没有重要内容被裁掉；视频是否真的解码，画面是否有合理高度，播放失败时页面是否给出可理解的状态。
第4轮发现的封面裁切，说明“图片地址有效”远远不够。第5轮把手机卡片改成单列，并让封面完整显示，解决的是内容被布局挤压的问题，而不是简单把图片放大。第6轮进一步验证了竖屏成片的实际解码播放，画面高度达到760像素。这个结果比“播放器加载成功”更有意义，因为它验证了媒体从地址到画面的完整链路。
这里最容易误判的，是把浏览器愿意渲染一个元素当成媒体验收通过。一个视频标签可以出现，画面却可能没有解码；一个图片框可以有尺寸，主体却可能被裁成只剩边缘。如果不处理，用户会在真正打开内容时才发现页面展示的是空壳。
真实照片还留下了一个必须明确记录的未完成项：它们没有预览映射。因此，我没有把照片加载宣称为验收通过。**没有证据的成功，不能因为页面看起来完整，就被写进完成结论。**这条边界看起来保守，实际是在保护后续判断不被一句“已经接上了”带偏。
移动端和异常态要单独走一遍
桌面宽度下能看清，不代表手机上也能用。真实数据让卡片内容变长以后，手机端的窄卡片问题很快出现：信息被迫挤在同一行，封面和文字互相争空间，用户需要反复猜每块区域的边界。第5轮改成单列，重点不是让页面更整齐，而是让每张卡片拥有足够的阅读宽度，并让封面完整显示。
我还把移动端看成一种独立的内容约束，而不是桌面布局的缩小版。真实数据改变了文字长度、图片比例和卡片数量，响应式布局面对的是一组新的输入。验收时必须实际走一遍手机宽度，检查是否横向溢出、重要信息是否被截断、触控区域是否仍然容易操作。只看桌面截图，无法替用户承担这些问题。
异常态也一样。第4轮已经发现加载失败后不能重试，这不是一个边角体验问题。网络抖动、资源暂时不可用或某次读取失败，本来就是媒体页面会遇到的正常情况。如果失败以后只能刷新整个页面，用户无法知道当前状态，也无法恢复刚才的上下文；如果页面静默地留在空白状态，使用者甚至不知道是没有内容还是加载失败。
所以第7轮和第8轮把看图大窗、键盘操作、深链、前进后退和错误重试一起复验。大窗要能居中并在暗幕中保持主体清楚，左右切换不能因为一张图片读取失败就被卡住；Esc 后焦点要回到原来的位置；深链打开时要保留正确上下文；前进后退要能回到用户刚才的状态；失败后要有可再次触发的恢复路径。它们共同回答的不是“按钮能不能点”，而是“用户中途遇到问题后，能不能继续完成任务”。
把验收从一次结论变成一张清单
这次之后，我不再把真实数据接入后的验收写成一句“页面已完成”，而是按风险拆成几组证据。先核对数量和字段，确认页面接到了什么；再检查图片完整性和视频实际解码，确认媒体不是只停留在临时展示层；然后走移动端布局，确认内容在窄屏上没有失去可读性；再走深链、键盘和前进后退，确认用户能进入、操作并离开当前上下文；最后制造一次失败，验证重试和恢复。
这套顺序有一个实际好处：它把“数据问题”“呈现问题”和“恢复问题”分开了。数量不对时，先不要急着调样式；封面裁切时，先确认资源映射和比例；重试失败时，先确认失败状态是否被页面真正捕获。每一项都要记录已证实的事实和仍缺少的证据，不能把相邻项目的通过结果借过来使用。
错误捷径是只看页面是否出现几张卡片，或者只看接口是不是返回了非空结果。这个捷径之所以诱人，是因为它很快，也很容易留下“完成”的截图。但它跳过了真实数据最重要的部分：内容形状、媒体终态和失败之后的行为。验收清单的价值，不是让检查显得更完整，而是阻止一个浅层成功替代真实完成。
表面上我是在检查一个页面，其实我是在检查一条从数据到使用结果的链路。一个流程成熟的标志，不是它能在顺利条件下跑通一次，而是它能明确指出哪些结果已经被证明，哪些结果还不能宣称。
下次我会怎么做
下次遇到页面从样例数据切换到真实数据，我会先暂停沿用旧结论，重新建立一张验收表。第一步记录真实数量和字段基线；第二步抽查图片完整性并实际播放视频；第三步用移动端宽度检查卡片、封面和文字；第四步打开深链，走键盘、前进和后退；第五步主动制造一次读取失败，确认用户可以重试并恢复；最后单独列出没有预览映射或证据不足的资源。
我会把“通过”写得更窄一些，把“未完成”写得更清楚一些。这样做不是降低交付速度，而是避免在后面用更大的代价返工。真实照片没有预览映射，就保留为未完成项；视频已经实际解码，就写清画面高度和验证范围；手机卡片已经改为单列，就说明它解决的是哪种内容拥挤。
这件事让我重新意识到，数据接入真正改变的不是页面里出现了多少内容，而是我们必须开始对内容的真实命运负责。它有没有被完整看见，能不能被顺利打开，失败后能不能回来，这些才是用户感受到的完成。我下次会先问“还有哪些终态没有被证明”，再问“页面是不是已经看起来完成”。