那4张没露出来的商品图，桌面用户不知道它存在，Googlebot也不会去翻

摘要：商品页图库放了9张图，默认只露出5张缩略图。桌面用户看到5张就以为一共5张，Baymard测试里有一半人没找到后面的图；手机用户不管有没有提示都会先滑一下试试，两拨人的默认结论正好相反。抓取程序连补都不补，Google官方文档明说它不会滚动也不会点击，你为人补的那四种信号对机器一个都不生效。这篇把缺口拆成人、辅助技术和抓取程序三个收件人，把overflow的五种写法、WCAG 2.5.8的24像素门槛和商品feed的10张上限摆进同一张表，再给五个不用埋点的指标，以及一个灯具站的复盘。

商品页上那5张缩略图，用户凭什么知道后面还有4张？

图一直都在，只是这一页从来没说过它存在。而用户不会把沉默当成沉默，他会替你补一句话，然后照那句话行动。

用户补的那句话，恰好是你没说的那句

先看一个具体场景。一个吊灯的商品页，图库里一共传了9张：正面、侧面、点亮效果、材质特写、安装示意、尺寸标注、包装清单、色温对比、实景搭配。缩略图条默认排5张，剩下4张要往右滑才出得来，而轮播两端没有箭头，也没有半张图露在边上，第5张的右边就是干干净净的留白。

一个正犹豫这盏灯挂在2.7米层高客厅里会不会太大的用户，点完5张缩略图没找到尺寸标注那张，去翻详情描述也没看到答案，于是回列表页换下一个商品。

尺寸标注那张图一直都在。它在服务器上，在数据库里，在这一页的代码里。摄影师拍过它，修图的人处理过它，运营把它上传过。整条链路上唯一没发生的事，是这一页告诉过用户它的存在。

这里有一个容易被略过的地方：界面在这个位置什么都没说，而用户不会把沉默当成沉默。他会替你补一句话，然后照那句话行动。这一次他补的是“就这5张”，于是他不再往下试。

沉默不是中立的。你以为自己什么都没说，其实那个位置上有一句话，只不过说话的人是用户，内容由他所处的环境决定，不由你决定。

三个问题问完，就知道这个位置有没有事

把这件事从图库里拎出来，它能变成一组到处都能用的问题。任何一个只展示了一部分的界面位置，都可以拿这三句过一遍。

第一句：这个位置我什么都没说，用户会替我补上哪一句？他补的那句不一定是错的，但它一定存在，而且一定会决定他下一步做什么。

第二句：不同设备、不同来源的用户，补的那句话一样吗？如果不一样，你就不是在做一个设计，你是在同时对两拨人说两句相反的话，而验收的时候只验了其中一拨。

第三句：他补错了会做什么动作？答案往往是什么都不做——不点、不滑、不问，直接换下一个商品。这就是这类问题最难被发现的原因：它在报表上不产生任何事件，只产生一次安静的离开。

同一件事，在你的站上还有多少个实例

图库缩略图只是最容易看见的那一个。凡是容器里装的东西比露出来的多、而露出来的那部分自己不说明这件事的地方，都是同一个问题的实例。

最后一行是留给你自己团队的。同一套逻辑做出来的默认视图，给用户看的时候叫可用性问题，给你自己看的时候叫决策依据。

这一篇不打算谈的几件事

有几个话题跟它长得像，机制却完全不同，混在一起谈只会把判断搞糊。

一是文本折叠的收录问题。一段正文被Show More收起来，Google照样能读到里面的字，因为它在DOM里，这跟能不能被人看到是两码事，风险边界在Show More文本折叠会拖累SEO吗里已经算过一轮。图片不一样，它牵扯到一次文件请求，差别在哪后面会讲。

二是分页还是无限滚动的选型。那是内容分多少批送到的问题，四种方案的机制对照在分页SEO和无限滚动到底怎么选里。本文谈的是同一批内容里露出来多少。

三是把商品页信息塞进横向标签、导致两块内容没法对照，那是相邻性问题，那排标签把商品页收拾得很干净讲的就是它。那种场景里用户知道内容存在，只是够不着；本文的用户连存在都不知道。

四是筛选状态的回显，用户忘了自己选过什么，属于连点五个筛选之后用户忘了自己选过什么的范围。那是记忆负担，本文是信息缺口。

为什么这类问题总是最后一个被发现

把上面第三句判据再往前推一步，就能解释一个长期现象：图库这类问题在绝大多数团队的问题清单上排得很靠后，不是因为它不重要，是因为它不会喊。

一个结账流程的报错会喊。用户点了提交、页面没反应，他会刷新、会重试、会去找客服，每一个动作都在你的日志里留下一行。一个价格显示错误会喊得更响，半小时之内就有人打电话进来。

图库不喊。用户看完5张图，得出一个结论，离开。他没有失败，在他自己的叙述里这次浏览很顺利——他看了这个商品，觉得信息不够，换了一个。他不会给你反馈，因为在他看来没有任何事情出错。

缺少信号的问题有一个共同特征：它把系统的缺陷伪装成了用户的选择。报表上记录下来的那次跳出，看上去和一次真实的兴趣不足完全一样，而这两者需要的应对方式恰好相反。

一个反例，用来划清边界

并不是所有的“只露出一部分”都有问题。列表页每页只显示24个商品，用户不会因此认为你只有24个商品，因为分页器本身就是一个非常成熟的完整性信号：它写着页码，写着总数，还告诉你现在在第几页。

同样，一段被Show More收起来的文字，那个按钮本身就是信号，用户知道下面还有。这两个例子说明，问题从来不是截断，是截断之后有没有留下一个能被看见的边界标记。

所以整篇文章要解决的事情，可以压缩成一句话：把那条本来就该在的边界线画回去，并且确认三个不同的收件人都能读到它。至于哪三个收件人，后面会展开。

为什么偏偏是图库，而不是别的模块

商品页上有十几个模块，为什么这条边界线最容易在图库这里丢掉？有一个结构性的原因：图库是整个商品页上唯一一个纯视觉的信息模块。

价格有数字，规格有文字，评论有星级和条数，库存有状态词。这些模块只要内容还在，用户至少能看到一个提示——参数表折叠了还有个“展开全部”，评论收起了还写着共214条。图库不一样，它的内容本身就是图，而图不会自己说明还有几张图。

更麻烦的是它的性质。图库不是页面的配件，它常常就是决策本身。Baymard反复出现的一句结论是：在大规模商品页测试里，商品图片一次又一次被证明对用户的购买决定至关重要。信息密度最高的那个模块，恰好是唯一一个不会自我说明的模块，这大概是商品页设计里最不划算的一个巧合。

这也是为什么图片本身的质量和真实感值得单独投入，图片越假信任越低怎么破和原创配图怎么把自然流量拉高讲的是同一件事的另外两个面。而本文谈的是最前面那一步：图得先被找到，后面那些才谈得上。

为什么桌面用户和手机用户，对同一排缩略图补的话正好相反？

一边默认就这些，一边默认应该还有。同一个截断，两拨人走向两种完全不同的失败。

桌面用户的默认答案是“就这些”

Baymard在图库隐藏缩略图必须给出指示这条准则里的原话是，把缩略图轮播截断而不加任何视觉指示，会让用户产生一个错误假设：默认能看到的这一组缩略图，就代表了全部数量。

更早那条用缩略图表示更多商品图把数字说得更死：当图库只用指示点来表示还有更多图片时，测试中50%的桌面用户在找这些额外图片时遇到了麻烦，其中一部分人完全没意识到还有别的图。

桌面用户为什么不试？Baymard给的解释挺朴素：桌面上默认主图占屏幕的比例不大，同一屏里还看得见规格选项、价格、描述，用户手上有别的事可做，探索图库的动力就低。他不是懒，是这一屏里还有六七个别的东西在争他的注意力，而图库没有开口喊他。

手机用户的默认答案是“应该还有，滑一下”

手机端的观察结论正好翻过来。同一份研究里写着：与桌面测试不同，移动测试中用户会假设更多图片存在，无论有没有做出指示；即使完全没有任何提示，用户也会习惯性地开始滑动主图。

原因不难理解。手机上主图往往占掉大半个视口，别的信息要滚动才看得到，图库几乎是他碰到的第一个东西；加上滑动这个手势已经便宜到不需要理由，试一下的成本接近于零。

所以在移动端，“漏看”这件事的形态变了。用户不会漏掉主图轮播里的图，他漏掉的是缩略图条里的图——他滑的是主图，不是那条缩略图带。源文里有一句反直觉的话正好说的是这个：正因为移动用户这么轻易就会用滑动手势，当图库使用隐藏缩略图时，用户漏看图片的风险反而可能比使用指示点时更大。

还有一条现成的结论顺手可以省掉一次争论：测试中没有观察到任何证据表明用户愿意为了看图库而切换屏幕方向。所以横屏空间大这个理由，在排期会上可以直接划掉。

一张对照表：同一个截断，两种失败方式

这张表最实用的一格是“在报表上的痕迹”。桌面那一格是空的，这意味着你在数据里看到的移动端问题，很可能只是桌面端同一问题的可见部分。移动端的坏数会先响，因为它至少产生了动作。

六年过去，行业改了多少

把两份研究的时间戳放在一起看，会得到一个不太舒服的结论。2020年那篇写的是：100%的桌面基准站使用缩略图，而移动站只有24%这么做。2026年更新的源文写的是：图库缩略图在移动端远不如桌面常见，近期测试中75%的移动站改用指示点。

两个数字不是同一个口径——一个统计的是“用缩略图的比例”，另一个统计的是“用指示点的比例”，中间还有既不用缩略图也不用点的第三种做法，所以不能当成严格同比。但方向是清楚的：六年时间，移动端图库的主流做法基本没动。

这件事值得单独拎出来说一句，因为它决定你该怎么给这个项目定性。有些体验问题会随行业自然改善，你等两年，组件库更新一版，问题就没了；这一类不会。移动端用指示点是一个省空间的主动选择，每一年都有人重新做一次这个选择，而且每次都能说出理由。它不是遗留问题，是一个持续被重新做出的决定。

换句话说，别把它放进技术债清单等着顺手还掉，它不在那条路上。

一个反直觉的推论：移动端的收益不在图上

按上面的分析，移动端补信号的收益应该比桌面低，因为用户本来就会滑。这个推论大体成立，但漏了一件事。

移动用户滑的是主图，他能一张一张翻完，代价是他必须把9张图按顺序过一遍，而且过程中没有任何东西告诉他还剩几张。缩略图条在移动端的真正价值不是提示存在，是提供一张目录——让他能直接跳到第7张，而不是老老实实滑七次。

这个区别决定了移动端该怎么排优先级：如果你的商品图普遍在5张以内，移动端保留指示点问题不大；一旦到了10张以上，缺的就不是提示而是索引。灯具、家具、乐器这类图多的品类，移动端缩略图条的价值被系统性低估了。

同一个站上，这两种失败往往同时存在

还有一个更容易被忽略的情况：很多站的桌面端和移动端是两套模板、两个组件、有时甚至是两个团队。Baymard的观察里就提到，不少站在桌面用缩略图、到了移动端换成指示点，理由是省屏幕空间。

这意味着两个平台的问题不是同一个问题的两个表现，而是两个独立的问题，需要分别排期、分别验收。合成一张需求单去做，最后往往是桌面那条被顺手做掉，移动端那条留在下一个季度。

顺带留一条判断给排期用：桌面的收益兑现得快而干脆，移动的收益兑现得慢但持续。桌面是从零到有，改完当周就能在日志里看到后段图片请求量的跳变；移动是把已有的滑动行为引导得更高效，它的曲线是缓慢抬升的。汇报节奏要按这个来安排，否则移动端那条很容易在第二周被判定为无效。

还有一件跟手势有关的事值得连起来看。移动端的滑动之所以这么便宜，是因为它已经被用户用成了肌肉记忆，而这也意味着同一个手势在一个页面上往往承担了好几种意思——翻图、翻页、返回、关闭浮层。这一层的完整讨论在同一根手指要负责翻页、握住手机和下单里，它解释了为什么移动端的滑动偶尔会失灵：不是代码写坏了，是这一下滑动被另一个监听器抢走了。

四种补救办法，各自只补回了信号的一部分

在它们出现之前，浏览器早就提供过一个一次说清三件事的元素。我们把它删了，然后花四种方案把它的活儿分包出去。

先说一句被删掉的东西：滚动条

在这四种方案出现之前，浏览器其实早就提供过一个完整的答案，就是滚动条。它一个元素同时说了三件事：这里面还有东西（滑块没占满槽）、大概还有多少（滑块占槽的比例）、我现在在哪一段（滑块的位置）。它还顺带提供了操作手段本身，拖它就能走。

然后设计把它删掉了，理由通常是它不好看，或者它在那条72像素高的缩略图带上显得又粗又碍事。删掉之后，那三条信息一起消失了，于是行业花了四种方案，把它的活儿分包出去，每个包工头只干其中一部分。

把四种方案摆进同一张表，能看清楚每一种到底补回了什么。

四种方案补回了信号的哪几个维度

看最后一行就明白为什么这四种方案在测试里经常需要两两组合使用了。源文里提到Polaroid的做法是半张图加箭头，LEGO是半张图再加一条滚动条，Away只用半张图。它们不是在做加法炫技，是在把一个元素拆散之后重新拼回来。

采用率与适用边界

源文给了两个采用率数字。最常见的成功做法是两端箭头这种手动轮播，近期测试中有一半的桌面站在用；末位放数字方块的做法稍少一些，大约三分之一的桌面站在用。半张图和全部展开没给比例，但都被记为在测试中表现良好。

全部展开这条要单独说，因为它是唯一一个把问题消灭而不是标注的方案。Baymard的表述是：桌面参与者浏览缩略图完全没有困难，哪怕缩略图排了两行；对于图片数量在10到14张以内的商品，直接把缩略图全部铺在商品页上，通常是最省事也最保险的做法。

限制在移动端。竖屏的横向空间就那么宽，全铺不现实。所以现实里的组合往往是桌面全铺、移动用半张图或箭头，这恰好符合上一节那个结论：两个平台的默认判断不同，本来就该给两套答案。

那个数字要不要标，研究说没差

末位方块上写“加5”还是只画个箭头，是这类需求评审上最容易吵起来的细节。源文对此有一句很干脆的话：虽然这种做法能顺带告知还有多少张隐藏缩略图，但测试中没有证据表明这个数字会影响用户是否去查看隐藏的图片。

这句话的价值不在于告诉你别标数字，而在于告诉你这一格不值得吵。愿意标就标，不标也不亏。把争论的时间留给真正有分歧的地方，比如移动端到底给不给缩略图条。

顺带一提，箭头的样式确实有讲究。源文的措辞很克制：虽然无法从测试数据里建立箭头样式与指示效果之间的因果关系，但把这类元素做得醒目些，会提高它被识别出来的概率。一个描边很浅、颜色接近底色的箭头，等于没画。

怎么选：三句话决定

第一句：桌面端图片数量的中位数在14张以内吗？是就全铺，这一条能一次性关掉桌面侧的所有讨论。

第二句：图库控件是自研还是第三方组件？自研就直接加半张图，改一个容器宽度的事；第三方组件先查它有没有暴露箭头和末位插槽，有的话优先用它自带的，别覆盖样式，否则组件升级会把你的改动冲掉。

第三句：移动端你更怕用户漏图还是更怕挤掉首屏空间？怕漏图就上缩略图条加半张图，怕挤空间就保留指示点，但指示点的尺寸必须过一遍无障碍门槛，这个门槛是有具体数字的，后面会讲到24像素那条线怎么算。

三种常见的组合搭法

实际落地时很少只用一种。把源文里提到的几个站的做法归一归，能得出三种成熟搭法。

第二种值得多说一句。把滚动条留下来，等于把上面那张表最后一行的能力找回来一部分——它是四种方案里唯一能同时表达“还有多少”和“我在哪”的做法，而后者在图片数量多的时候比前者更重要。用户翻到第12张的时候，他真正想知道的是还剩几张，好决定要不要继续。

轮播这个控件本身的基准

顺带把这个控件放到更大的背景里看一眼。Baymard在首页轮播的10条要求里给了两个数：33%的电商站首页有轮播，而其中46%的实现存在可用性问题。

这个比例说明，轮播不是一个难以理解的控件，而是一个容易做错的控件。它把可见内容和可用内容拆成了两件事，而这个拆分需要额外的信号来弥合，恰好这个信号又是最容易在设计精简的过程中被删掉的东西。

所以真要给一条通用建议的话：凡是能不用轮播的地方就别用。商品图库属于不得不用的那一类，因为图片天然要占空间；首页那个大banner通常不属于，把它换成两三张并排的静态图，问题自己就消失了，前端复杂度还降了一大截。

全部展开那一条，代价到底有多大

全铺是唯一一个把问题消灭的方案，但它会带来一个真实的顾虑：图片多了，页面重了。这个顾虑值得认真对待，因为它是后面那个复盘里所有事情的起点。

先把账算清楚。缩略图是小图，不是大图。一张80像素见方的缩略图压成WebP通常只有几KB，多铺8张增加的字节数，往往比页面上任何一个第三方脚本都少。真正重的是主图和浮层里的高清版本，而那两样跟铺不铺缩略图没有关系。

所以正确的做法不是在“全铺”和“性能”之间二选一，是把这两件事拆开处理：缩略图全铺并且全部写进初始HTML，主图用优先级提示提前，浮层大图按需加载。三种资源三种策略，具体的优先级机制在关键渲染路径怎么优化里有更完整的拆解。

如果确实需要跳过屏幕外那部分的渲染开销，还有一条更温和的路径，就是让浏览器跳过渲染但保留内容，这类做法的边界在content-visibility是什么里讲得比较细。关键的区别在于：跳过渲染和不加载内容，是两件完全不同的事，而它们在性能报告上长得很像。

同一个看不见，CSS里有五种写法，后果差多少？

设计稿上它们长得一模一样，改一个单词，页面截图不会有任何变化，但键盘用户的处境天差地别。

五个值，五种“看不见”

设计稿上这五种写法长得一模一样：一条缩略图带，右边被容器切齐。但它们在浏览器里是五件不同的事。MDN的overflow属性文档把差别写得很细，整理成表是这样。

倒数两行是这张表的重点。hidden和clip渲染出来的画面完全一致，改一个单词，页面截图不会有任何变化，但键盘用户的处境天差地别。

clip那一行，MDN自己写了后果

MDN在讲clip的例子时有一句直白的结论：Tab到被裁剪内容里的输入框会让它获得焦点，但不会把它滚进视口，这使得那部分内容对键盘用户不可访问。

换成图库的场景：一条用clip裁齐的缩略图带，第6张之后的缩略图仍是可聚焦的链接，键盘用户按Tab键，焦点走进去了，屏幕上却什么都没动。他的处境是焦点停在一个看不见的地方，按回车会跳到一张不知道内容的图。

hidden至少还保住了这一条：焦点进去，浏览器会把它滚进视口。所以如果你的图库不打算给用户提供任何手动滚动手段，只靠按钮驱动，MDN给的建议是用overflow: hidden而不是把滚动条宽度设成none。这两种写法看上去都是“没有滚动条”，可达性不一样。

把滚动条藏起来这件事，规范作者预见到了

另一个常见动作是保留滚动能力、只把滚动条变细或者干脆隐形，也就是scrollbar-width这个属性。MDN的说明里有两句话值得贴在需求文档上。

第一句是关于用途的：这个属性的目的是优化滚动条占用的空间，与滚动条的美观无关。绝大多数人用它的理由恰好是它明说自己不管的那件事。

第二句是一条警告：谨慎使用这个属性，把它设成thin或none有可能让内容变得难以滚动甚至无法滚动，除非作者提供了替代的滚动方式。这条警告的措辞不是“会变丑”，是“用户可能滑不动”。

MDN在同一段里还顺手点到了两条无障碍准则：WCAG 2.1.1的键盘可达要求早就适用于内容区的滚动，而WCAG 2.1新增的2.5.5目标尺寸建议触摸目标要足够大。滚动条这个东西，本身就是一个触摸目标。

还有一个你在自己机器上看不见的版本

scrollbar-width的auto值，MDN的定义是“该平台的默认滚动条宽度”。这句话里藏着一个很难被发现的坑：默认值是平台给的，不是你给的。

在一部分系统和浏览器上，滚动条只在真正滚动的那一刻浮现出来，平时既不占空间也不显形；在另一些环境里，它是一条常驻的、占据实际宽度的槽。同一份CSS，同一个组件，一边有完整性信号，另一边没有。

顺便说一句overflow的overlay值。MDN写得很清楚：它是auto的遗留别名，最初是作为非标准值实现的，用来把滚动条画在内容之上而不占空间，现在不建议在新代码里使用。这个值当年之所以存在，恰恰就是因为有人想要“滚动条别占地方”，而它带来的正是本节讨论的这个后果。

这件事的麻烦之处在于验收环节。写代码的人、做设计的人、做测试的人，很可能都在同一类设备上工作，那么丢失信号的那个版本谁都没见过。这不是粗心，是采样问题：团队的设备构成和用户的设备构成从来就不是同一个分布。

10秒自测

不需要工具，打开一个图片多的商品页做三个动作。第一，把浏览器窗口拖窄到375像素左右，看那条缩略图带右边有没有任何东西告诉你还有更多。

第二，鼠标点一下主图，然后一直按Tab键，数一数焦点走过了几个缩略图，以及在焦点走到第6张的时候，画面有没有跟着动。如果焦点计数在涨而画面纹丝不动，你大概率写了clip。

第三，把手指或触控板放在缩略图带上横向滚一下。滑不动而箭头又不明显的话，你现在看到的就是用户看到的全部。这三下花不了10秒，比任何一次评审都更快得出结论，具体到批量体检可以配合一页图片的alt与属性批量体检那套做法一起跑。

一份可以直接抄进代码评审清单的判断

把上面这些整理成四句，评审的时候照着问就行。

第一句：这个容器需要用户能自己滚动吗？需要就用auto或scroll，别用hidden之后再自己写一套拖拽。自己写的那套通常没处理键盘，也没处理惯性滚动。

第二句：这个容器里有可聚焦的元素吗？缩略图几乎一定是链接或按钮，那就是可聚焦的，这一条直接排除clip。clip只适合装纯装饰、没有任何交互的东西。

第三句：如果决定不显示滚动条，替代的滚动手段是什么？箭头按钮算，滑动手势算，但滑动手势在桌面端不成立——桌面用户没有触摸屏，触控板的横向滚动也不是人人都会用。所以桌面端隐藏滚动条时，必须配一对可见的箭头，这不是体验优化，是功能完整性。

第四句：这个判断在窄屏下还成立吗？很多图库在桌面宽度下压根不溢出，所有问题都不存在；一旦窗口变窄或者换成平板，它才变成一个滚动容器。断点两侧的行为要分别验一次，只验一个宽度等于没验。

还有一类容易被忽略的截断：垂直方向

前面讨论的都是横向缩略图带，但有相当一部分站的桌面图库把缩略图竖着排在主图左侧。竖排的截断更隐蔽，因为用户对纵向滚动的敏感度天然比横向低——整个页面本来就在纵向滚动，那一小段独立的纵向滚动区域很容易被当成页面的一部分。

源文里提到Grainger的移动站就是在竖排缩略图上放了一个数字方块，表示还有3项。这个做法在竖排场景里比箭头更管用，因为竖排的箭头很容易和页面本身的滚动提示混淆。

竖排还有一个额外的坑：它经常被写成固定高度加overflow隐藏，而这个高度是照着主图高度定的。主图一旦换成不同比例的图，缩略图区的高度跟着变，能露出几张就变成了一个随商品而变的数字。你在测试环境看到的6张，在另一个品类可能是4张。

那排小圆点点不准，无障碍标准里写了具体数字吗？

写了，24乘24 CSS像素，还给了一套用圆圈判断间距的算法。有意思的是它的例外条款，恰好在最需要它的时候失效。

先看用户是怎么点歪的

Baymard那份移动端观察里有几个很具体的片段。一位用户在Under Armour上说：现在我只能去戳下面那些点，因为滑动一直有问题。另一位在Sephora上想用指示点翻图，结果手指落在了主图上，屏幕上弹出了放大浮层，她的原话是：刚才发生什么了？哦，我不需要看大图。

研究给的结论是：移动端翻图几乎全靠滑动手势，指示点通常只在滑动没反应或者反应不好时才被当成备用手段；而一旦真的用上，这些又小又密的命中区常常造成误触，用户点到相邻的那一个，跳到一张他没想看的图。

这是一个定性观察。有意思的是，同一件事在无障碍标准那边有一个量化门槛，两边说的完全是一回事，只是没人把它们放在一起过。

24像素那条线是怎么算的

WCAG 2.2新增了一条AA级成功准则2.5.8，叫目标尺寸（最小值）。W3C的理解文档把要求写成一句话：指针输入的目标尺寸至少为24乘24 CSS像素，另有五种例外。

它的意图写得也很明确：确保目标能够被轻松激活，而不会误激活相邻的目标。这跟上面那位用户点到了旁边那个点，是同一句话的两种说法。

五个例外里，跟指示点直接相关的是第一条，间距例外。原文的判定方式很具体：对于小于24乘24的目标，以每个目标的包围盒为圆心画一个直径24 CSS像素的圆，这些圆彼此不相交，也不与其他目标的圆相交，就算通过。

拿常见的图库指示点算一下就知道结果了。一排直径8像素、间距8像素的圆点，圆心之间的距离是16像素，画两个直径24的圆必然重叠。这一条走不通。

那条“等效控件”的例外，恰好在最需要它的时候失效

五个例外里还有一条叫等效：如果这个目标本身不够大，但页面上另有一个能实现同样功能、且满足尺寸要求的控件，那么这个小目标可以被豁免。

听上去指示点稳稳落在这条例外里——毕竟主图本身又大又能滑，滑动就是那个等效控件。逻辑上没问题。

但把它和Baymard的行为观察放在一起，会看到一个不太舒服的缝：用户去点指示点的时刻，恰恰是滑动已经失灵的时刻。等效例外成立的前提是那个等效控件一直可用，而现实里用户启用备用方案，正是因为主方案当场不好使了。

这不是说标准写错了。标准描述的是页面的静态属性，而失灵是一个运行时状态。这条缝提醒的是另一件事：凡是按“还有别的路可以走”来豁免的设计，都值得再问一句，用户走上这条备用路的那一刻，主路是不是正好塌了。

顺带把两个尺寸数字分清楚

多数团队的验收清单里只有44这个数，于是要么按AAA的标准把所有小控件推倒重做，要么因为做不到而整条放弃。24这条线更现实，而且它自带一条可以退让的路径——尺寸不够就把间距拉开，这对一排指示点来说通常只要改一个gap值。

还有一条2.2的新准则，跟图库撞得很实在

成功准则2.4.11叫焦点不被遮挡（最小值）：当一个界面组件获得键盘焦点时，它不会因为作者创建的内容而被完全隐藏。理解文档里点名的典型元凶是粘性页脚、粘性页头和非模态对话框。

商品页恰好是这三样最爱扎堆的地方。移动端下面常年悬着一条加购栏，上面常年吸着一条搜索栏，中间那条缩略图带如果又靠近视口底部，键盘焦点走到某一张缩略图时，被悬浮栏整个盖住是很自然的事。

理解文档给的通过办法有两条：把那个覆盖层做成模态的，逼用户先处理掉它；或者用滚动内边距为焦点留出空间。后者对图库来说更实用，也不影响视觉。

还有一个越来越现实的理由值得把这一节做扎实：读你页面的不止人和搜索引擎。AI浏览器读的是无障碍树，不是你那张页面截图说的就是这件事——语义和焦点顺序做得好不好，现在直接决定了智能体能不能把你的商品图数清楚。

命中区这件事在桌面上更严重，这有点反直觉

说到命中区，很容易默认它是移动端专属问题，毕竟手指比鼠标粗。Baymard有一份数据把这个印象推翻了：在视觉元素里的可点区域通向哪里这条准则上，33%的站点不合格，拆开看是移动端28%、桌面端43%。

桌面反而更差，原因不在尺寸而在边界。一个视觉块里常常塞着标题、缩略图、评分、按钮，可能通向四个地方，也可能整块是一个大链接，用户无从判断。研究举的例子是Crutchfield：标题和缩略图去同一个地方，点评分星级却跳到评论区。

这跟图库截断是同一个族的问题——都是界面没有表达清楚一个边界在哪里。一个是集合的边界，一个是可点区域的边界。做图库改造的时候顺手把这一条一起验了，成本几乎为零。

键盘那一条比想象中管得宽

很多人对WCAG 2.1.1的印象是“表单和按钮要能用键盘操作”。这条准则的理解文档覆盖面比这个宽，而MDN在讲滚动条时特意点了一句：内容区域的滚动本身就应当包含在基本的键盘可达要求之内。

换句话说，一个滚动区域能不能用键盘走完，不是加分项，是基本项。这句话对图库的意义很直接：如果你的缩略图带只能靠鼠标拖或者手指滑，那它在这条准则上是有问题的，跟好不好看无关。

好在图库这个场景的修法很便宜。缩略图本来就是链接或按钮，天然可聚焦，只要容器不是clip，Tab键就能把它们逐个带进视口。真正需要额外做的只有一件事：确认焦点样式没有被全局样式表里那句去掉轮廓的规则干掉。这句规则在很多主题里是默认存在的，它一行就能把整个键盘体验废掉。

把无障碍这件事放回它该在的位置

这一节想留下的不是一份合规清单。真正有用的是另一个认识：无障碍标准给出的往往是同一个体验问题的量化版本。

Baymard说用户点不中那排圆点，这是观察；WCAG说至少24乘24 CSS像素或者满足间距判定，这是数字。两者描述的是同一件事，而它们通常分别躺在两个部门的文档里——体验研究归设计，无障碍归前端或合规，没有人把它们并排读过。

这个割裂造成了实际损失：体验问题拿不出可验收的门槛，合规要求讲不出为什么要做。前者在排期会上永远输给有数字的需求，后者永远被当成额外负担。把两边接起来，一句话同时解决两个麻烦——把这排圆点的间距拉开，既让用户少点错，也顺手过了一条AA级准则。

保哥的做法是在体验评审的清单里直接写上准则编号，不写解释。写编号的好处是它可以被查证，而形容词不行；说这个点太小了会引发讨论，说它不满足2.5.8只会引发测量。

Googlebot会替用户滑那一下吗？

官方文档里有一句话把前面几节的讨论整个换了坐标系：Google搜索不会与你的页面进行交互。

官方文档里那句话，值得逐字读

Google搜索中心讲修复懒加载内容的那一页，在列完三种推荐的懒加载实现方式之后，写了这么一句：上述方法不依赖用户操作（例如滚动或点击）来加载内容，这一点很重要，因为Google搜索不会与你的页面进行交互。

这句话把上面几节的讨论整个换了一个坐标系。用户漏看隐藏缩略图，是因为你没告诉他还有更多；抓取程序漏看隐藏缩略图，是因为它根本不会去点、不会去滑，它连“我可能漏了什么”这个念头都不会有。

两边的失败原因不一样，导致的结果是：修好一边不会顺手修好另一边。而它们在同一段代码里表现为同一个症状，就是那几张图没被看到。

四种信号，对机器一个都不生效

回头看上面那四种补救方案，它们共同的形式是“提示用户去做一个动作”。箭头是提示你点，半张图是提示你滑，数字方块是提示你点开浮层。而机器不做动作。

这张表最有意思的地方在最后一行。四种方案里唯一同时修好两个收件人的，恰好是最不需要动脑的那一个：干脆别截断。它之所以两边通吃，不是因为它更聪明，是因为它压根没有创造出一个需要被跨越的动作。

由此可以得到一条能反复用的判断：给人补信号，做的是让他愿意去做那个动作；给机器补，做的是取消那个动作的必要性。两者方向正相反。你在需求文档里写的每一条，最好先想清楚它属于哪一类。

Google到底认哪种图片

Google图片的最佳实践文档里有一条经常被忽略的硬规则：只有出现在img元素src属性里的图片才会被编入索引，即便这个img是picture等其他元素的子元素也算；CSS里的图片不会被索引。

把这条规则套回图库，就能画出一条很清楚的分界线。

第三行是本节最需要警惕的一种。它在人肉验收里永远通过，因为验收的人一定会滑一下——不滑他没法验。人的通道完好，机器的通道断了，而两条通道共用同一段代码。

顺带把两条容易混的事说清楚：给图片改文件名不会让网页排名变好，具体的边界在图片文件名是排名因素吗里算过；alt同理，它的真正用处在图片alt是排名因素吗里。本节讲的不是权重，是有没有被拿到，这是更前面一层的问题——没拿到，后面所有优化都无处附着。

正确的懒加载长什么样

Google那页文档列的三种做法是：浏览器内置的图片和iframe懒加载、IntersectionObserver API加一个polyfill、以及支持元素进入视口时加载数据的JS库。三种的共同点是触发条件为“进入视口”，而不是“用户做了什么”。

同一页还有一条反向提醒：不要给打开页面时就立刻可见的内容加懒加载，那会让内容显示得更慢，用户能明显感觉到。主图通常就属于这一类，它更应该被提前，相关的优先级控制手段可以参考fetchpriority是什么那篇里的机制。

如果你的图库浮层是点开才请求整组大图，那么浮层里的东西对抓取程序等于不存在。这不一定是问题——浮层里那份通常是大图版本，页面上已经有缩略图和主图在承担索引任务。要判断有没有事，方法很简单：用curl拉一次页面源码，数一数里面有几个img的src指向商品图，跟你后台上传的张数对一下。差多少，就是机器看不到的那部分。

需要提一句的是渲染。Google现在会执行JavaScript，但执行不等于交互，这两件事经常被混为一谈，Google取消JS SEO警告后到底该不该上SSR和框架站怎么做SEO把渲染这一层讲得比较细。可以这么记：脚本会被跑，但没有人替你滑那一下。

无限滚动那条规则，图库也适用

同一页文档还讲了无限滚动：要让无限滚动可被索引，网站必须支持这些内容块的分页加载，每一块都要有自己可以直接访问的地址。

这条规则的内核跟图库是一样的：内容不能只存在于一次交互的结果里，它得有一个不需要交互就能到达的形态。列表页那一侧的完整做法在分页SEO和无限滚动怎么选里，图库这一侧的对应物就是初始HTML里那几个img标签。

把这两条规则合起来记，图库这件事就只剩一句话：凡是要靠一次动作才出现的内容，都只对会做动作的那一半读者存在。人会做动作，所以他还有救，无非是慢一点、麻烦一点；机器不会，所以它连自己漏掉了什么都不知道。

放大浮层里那份大图，算不算漏了

这是实操里最常被问到的一个细节。多数图库的结构是三层：缩略图、页面上的主图、点开之后浮层里的高清大图。前两层通常在初始HTML里，第三层往往是点开才请求。

结论是通常不算漏。同一张图的三个尺寸版本，只要有一个版本以img的形式出现在页面里，这张图的内容就已经被表达过了。真正需要注意的是另一种做法：缩略图用了极小的占位图，真正有内容的版本只存在于浮层里——这时候机器拿到的是一张模糊的小图，内容识别的效果会打折。

顺带把清晰度这一层补上。Baymard的商品图分辨率与放大级别那条准则的数字是25%的站不合格。这跟本文是两个独立的缺口：一个是有图但找不到，一个是找到了但看不清。两个都会导致同一个结果，用户带着没解决的疑问离开，所以做图库改造的时候值得一起验。

多尺寸方案该怎么写才两边都不亏

Google那份文档专门讲了响应式图片的两种写法：用img的srcset属性列出同一张图的不同尺寸版本，或者用picture元素包住多个source来提供不同格式。这两种写法都被明确支持，抓取程序会正常处理。

需要留神的是picture的用法，文档里给的示例是先列svg和webp的source，最后那个img才是兜底。兜底的那个img才是索引的锚点，所以它的src和alt都不能省，也不能填一张占位图。

这一条在自研组件里最容易出错：为了图省事，兜底的img被写成了一个1像素的透明图，真正的图全靠脚本换进去。视觉上完全正常，性能报告也漂亮，但机器拿到的是一张空白。判断办法还是那一句，curl一次源码，看img的src指向的是不是真实的商品图。图片SEO那一侧更完整的清单在图片SEO优化的文件名、alt、WebP与懒加载怎么落地里。

同一组商品图，在四个通道里有四个上限

页面、商品数据文件、结构化数据、图片站点地图，四道关卡各有各的线，而它们从来没在同一次会议上被讨论过。

四个通道，四个上限

同一个SKU的那9张图，会通过四条完全不同的路走出去，每条路上有一道自己的关卡，而这四道关卡从来没在同一次会议上被讨论过。

最后两行的“没人”不是玩笑。图库归前端管，feed归运营管，这两条线各自都有明确的负责人和验收标准；而结构化数据里的图片字段和图片站点地图，往往落在两条线之间，属于谁都能改、谁都不觉得是自己的活儿。

feed那道10张的线

Google商品中心的附加图片链接属性说明写得很直接：可以提交多张图片，最多10张，多个网址之间用逗号分隔。加上主图字段那一张，一个商品在feed里最多能表达11张图。

同一页还提到了另一个字段，生活方式图片链接，用来提交商品在真实场景里的样子，文档举的例子是模特身上的衣服、摆在房间里的家具。这个字段值得单独留意，因为大部分站的场景图是混在附加图片里提交的，等于自己占掉了那10个名额里的好几个。

这里有个巧合值得一提，但别把它当因果：Baymard给的桌面全铺安全区间是10到14张，feed的硬上限是1加10。一个数字来自人的视觉耐受，另一个来自平台的字段设计，两者毫无关系，却撞进了同一个区间。真要说有什么启示，大概是：一个商品需要多少张图才说得清楚，这件事的答案没那么发散。

被砍掉的总是同一批图

这四个通道的截断方向是一致的：都从尾部砍。页面上砍的是第6张之后，feed里砍的是第12张之后，用户的耐心砍的是他点开的第3张之后。

而运营上传图片的顺序，通常是拍摄和交付的顺序：白底主图先到，场景图其次，安装示意和尺寸标注这类需要另外画的图最后到。于是被砍掉的那一批，恰恰是回答具体问题的那一批。

白底主图回答的是“这是什么”，用户看一眼就有答案；尺寸标注图回答的是“它放得下吗”，那才是他犹豫的地方。四道关卡各自独立地、无意地，把回答犹豫的那些图全都留在了门外。

顺序是唯一一个对四个通道同时生效的杠杆

这一节真正能带走的动作只有一条。你改不了feed的10张上限，改不了用户的耐心，短期内也未必改得动图库组件；但你能改图片的排列顺序，而顺序对这四个通道同时生效。

具体怎么排，有一条比“好看优先”更有依据的排法：把最容易引起犹豫的那个问题对应的图，放在第2或第3位。第1位留给白底主图，因为它同时承担列表页封面和搜索结果里的展示。第2位开始，按你客服工单里出现频率最高的问题排。

灯具是尺寸和色温，家具是尺寸和材质细节，服装是版型和面料垂坠，工具是接口规格和配件清单。这个顺序不需要调研，客服那边现成的，翻一周的工单就能排出来。

顺手把两条没人管的通道接上

结构化数据里的图片字段，把图库里的图全写进去，成本几乎为零，而它是Google挑缩略图时参考的元数据之一。

图片站点地图更省事，而且有一条常被忽略的便利：图片站点地图允许在图片地址里使用其他域名，这意味着图放在CDN上也能正常提交，具体写法可以参照免插件做sitemap时的image节点那套结构。

做完这两件事，你就得到了一个之前没有的东西：一份关于“这个商品到底有几张图”的机器可读答案，而它不依赖任何人去滑动。至于feed本身该不该被搜索引擎收录、怎么控制，那是另一个话题，在接口和feed这类地址拿什么说自己不想被收录里有单独一套办法。

顺带说一句更长远的：图片正在从页面的附属品变成一个独立入口，视觉搜索怎么让出海产品被找到和Google图片搜索混入购物广告之后免费流量还守不守得住讲的都是这个趋势。你藏在第8位的那张细节图，在页面上是一个可用性问题，在图片搜索里是一个没被建立的入口。

一次半天就能做完的四通道盘点

这一节听上去要动的东西不少，但第一次盘点其实很快。挑20个代表性SKU，横向铺一张表，四列分别填：页面默认露出几张、数据文件里提交了几张、结构化数据里写了几张、站点地图里有没有。

保哥带团队做这个盘点时的经验是，四列数字全都对得上的站，一个都没遇到过。最常见的形态是页面6、数据文件3、结构化数据1、站点地图空——四个通道说了四句不同的话，而这四句话描述的是同一个商品。

更值得记的是这张表填完之后的反应：它不需要论证，谁看到那四列数字都会立刻明白问题在哪，它本身就是最有效的立项材料。相比之下，讲用户在图库前的心理过程要花二十分钟，还未必说服得了人。

那张主图，还兼着另外三份工

顺带说一件容易被忽略的事：第1张图不只是图库的第一张，它同时是列表页的封面、搜索结果里的缩略图、以及社交分享时抓到的那张预览。它的选择标准和后面几张完全不同。

Baymard在商品列表里至少给3张缩略图那条准则里讲的是列表页的版本——用户在列表上就想多看一两个角度。这意味着你的图片排序不只服务商品页，它还在决定列表页上用户看到的是哪几张。

所以前面那条排序建议要加一个约束：第1位必须留给最能说明这是什么的那张，通常是干净的白底主图；从第2位开始才按客服问题排。把尺寸标注图放到第1位是过度矫正，它会让列表页变得难以浏览，而列表页的浏览量比商品页大一个数量级。

这四份清单该由谁来对

盘点做完，下一个问题立刻会出现：以后谁来保证它们一直对得上。这个问题不解决，半年之后一切照旧。

有三种常见答案，只有一种能活下来。第一种是排一个季度性的人工核对，通常执行两次之后就没人做了，因为它枯燥且没有即时反馈。第二种是指定一个负责人，问题在于四个通道分属四个系统，没有哪个岗位天然覆盖全部，指定谁都不合适。

第三种是把它挂到一个已经在跑的流程上。最合适的挂载点是商品上新流程：新品上架时本来就要填数据、上图、提交数据文件，在这条流水线的末尾加一个自动校验——页面里的商品图数量、数据文件里的数量、结构化数据里的数量，三个数不一致就报警。

这条经验其实比图库这件事本身更通用：凡是需要长期维持的一致性，都不该做成一次专项，要做成一个卡点。专项有开始有结束，而一致性没有结束的那一天。商品数据质量的其他几条线，比如描述文案的唯一性，也适用同一条原则，产品详情页怎么摆脱供应商文案里讲的是同一个道理的另一个应用。

这排缩略图同时发给三个收件人，你只改对了其中一个？

用户的眼睛、辅助技术、抓取程序。三条通道互不相通，而验收的人往往只代表其中一个。

三个收件人，三条互不相通的通道

那条缩略图带是一次广播，它同时发给三个收件人：用户的眼睛、辅助技术、抓取程序。三者接收信息的通道完全不同，所以一次改动通常只对其中一个生效，而验收的人往往只代表其中一个。

这张表可以直接贴进需求文档的验收标准那一栏。它比图库可用性优化这类描述有用得多，因为它把一个模糊目标拆成了三个能被证伪的条件。

改动分两堆，判据只有一句话

把待办事项分堆，用这一句去切：这个改动会不会改变“用户不做任何动作就能拿到的东西”。

不会改变的，归第一堆。加箭头、末位露半张图、把箭头描粗、把指示点的间距拉到过线、给焦点加滚动内边距——这些全都是在已经渲染出来的东西上加提示，风险低，前端一个人一周之内能做完，不需要拉任何其他角色。

会改变的，归第二堆。桌面全铺不截断、把事件触发的懒加载改成视口触发、把图片补进feed和结构化数据、给图库图建站点地图——这些会同时改变三个收件人拿到的东西，必须拉上做SEO的人和管商品数据的人一起排。

这句判据的好用之处在于它不需要你先懂技术细节。产品经理拿着需求列表，一条一条问“用户什么都不做的时候，这一条改了没有”，就能把两堆分开。

最忌讳的是拿第一堆的人力去啃第二堆。半途而废的典型后果是留下一个混合状态：一部分图在初始DOM里，另一部分靠事件注入，页面上看着一切正常，排查的时候没有任何规律可循，比动手之前更难办。

三档投入怎么估

第三档最花时间的不是技术，是补拍。某个品类普遍缺尺寸标注图，就要重排一轮拍摄和制图，这个周期由供应链决定，所以它必须最早启动、最晚验收。

第一次会该请谁

两个角色必须到场，而他们通常都不在这类会议的默认名单上。

第一个是拍图和修图的人。他知道第8张图当初是为了回答什么问题拍的——很多时候那张图的存在本身就是一次客服反馈的产物，只是没人记录过这件事。他还能当场说出哪些品类的图是套模板批量出的，哪些是一个一个做的。

第二个是前端。他知道那个图库是自研的还是第三方组件，能不能改，改了会不会在下次升级时被冲掉。这个信息决定了第一堆的工作量是一天还是两周，差别很大，而它没写在任何文档里。

保哥的经验是，这两个人到场，第一次会通常一个小时就能出排期；他们不在，会开三次，每次都卡在“这个能不能改”上。

立项时怎么说

这个项目不好立项，因为它听上去像是在给一个已经能用的功能做微调。有一个说法比“提升转化”更容易通过。

这些图已经拍完了，钱已经付过了。摄影费、修图费、上传工时，第8张图的成本跟第1张一模一样，唯一的差别是它没有被看到。你不是在申请一笔新预算，你是在申请把已经花掉的那笔钱兑现。

这个说法之所以有效，是因为它把讨论从“值不值得投入”换成了“要不要止损”，而后者在任何一张预算表上都更容易过。

谁该先做，谁可以往后放

最该先做的三个条件叠在一起：客单价中高、单品图片数量多、买之前需要看细节才敢下单。家具、灯具、乐器、工具、婴童出行、户外装备都在这一档，商品页本身该怎么搭在产品详情页的模块结构里有更完整的清单。

可以往后放的是图天然就少的品类。耗材、书、标准件，一个商品拍三张就说完了，它没有这个问题，因为它压根没有第6张图。

单独提醒一类站：刚从平台搬到独立站的团队。平台的图集通常有硬性上限，一个商品能传的张数就那么多，团队因此从来没有遇到过截断这件事——不是他们做得好，是他们没有机会遇到。等到自己开始拍图、图片数量翻了一倍之后，图库控件还是当年照搬过来的那一套，问题就在没人预料的地方出现了。

排期时最容易被砍掉的那一条

三档清单里有一项每次都活不到最后，就是图片站点地图。它排在最后，做起来最枯燥，而且做完之后没有任何人能在页面上看到变化——这三个特征凑在一起，它在任何一次排期压缩里都是第一个被划掉的。

但它恰好是唯一一条不依赖页面渲染的路径。前面所有改动都建立在“页面得先被正确渲染”这个前提上，站点地图不需要这个前提。等到哪天有人改了图库的加载方式，它就是那个还在正常工作的备份通道。

所以给它一个更容易活下来的位置：把它挂在第一堆而不是第三档。它跟前端改动没有任何依赖关系，可以在项目开始的第一周就做完，成本是半天。

验收标准怎么写才不会被糊弄过去

这类项目最常见的验收标准是“图库可见性优化上线”，然后大家一起在预发环境点几下，通过。问题在于点几下的那个人一定会滑动，而滑动恰好绕过了要验的东西。

把验收标准换成三条可证伪的：桌面窗口375像素宽时，缩略图带右侧存在可见的边界提示；从主图开始连按Tab键，焦点能走到最后一张缩略图且画面跟随滚动；curl页面源码得到的商品图img数量，等于后台上传的张数。

这三条的共同特征是不需要主观判断，任何人执行都会得到同一个结果。而第三条尤其重要，因为它是唯一一条无法用滑动蒙混过去的——后面那个复盘里，出事的正是这一条。

不加一行埋点，先算哪五个数？

五个数全都来自你已经存了很多年的东西：访问日志、商品数据文件、搜索控制台和客服工单。

第一个数：后段图片触达率

这个数的原料你已经存了很多年，就是服务器或者CDN的访问日志。每一张商品图被看到，都对应一次真实的文件请求，这件事从来不需要埋点。

算法：取一段时间内某个SKU的图片请求，第6张及之后的请求总数，除以第1张的请求数。这个比值就是后段触达率。按设备类型切开算，因为上面已经论证过，两个平台的用户行为方向不同，合起来算会互相抵消。

有一个口径坑必须先说清楚：浏览器缓存会让重复访问不发请求，所以这个数天然偏低。它不能当绝对值用，只能横向比——不同品类之间比、改版前后比、不同设备之间比。把它当成一个指数，不要当成一个百分比去汇报。

第二个数：请求断点的形状

第一个数给的是一个标量，这个数给的是一条曲线，而曲线的形状比数值有信息量得多。

把每次会话请求到第几张图就停了统计出来，画一条衰减曲线。兴趣衰减是平滑的：看到第3张觉得够了的人，比第4张停下的人略多一点，一路缓缓下滑。设计造成的截断不是这样，它是一个台阶——第5张和第6张之间会有一道陡崖。

这条判据的好处是它不需要任何基准值。你不需要知道多少算好，你只需要看这条线是斜坡还是台阶。台阶出现在哪个位置，那个位置就是你的默认展示张数，两个数字对得上，结论就成立了。

第三个数：图片搜索那一侧的覆盖

Search Console里有一个搜索类型的筛选器，把它切到图片，看两件事：图片搜索带来的展示与点击的量级，以及有多少SKU的图从来没在这里出现过。

这个数免埋点、现成、免费，但绝大多数团队没看过，原因很朴素：默认视图不显示它，要多点一次才切得过去。这里有一条值得记很久的经验——一个通道的数据如果需要在报表里多点一次才能看见，它在组织内部就等于不存在。后面那个复盘会讲到这句话的代价。

第四个数：feed里的溢出率

拿你正在提交的商品数据文件，算两个比例：附加图片字段填了几张的分布，以及有多少SKU的实际图片数超过了11张这条线。

超出的部分不是消失了，是被你自己按上传顺序截掉了。把这批SKU单独拉一张表，看看被截掉的是哪几张——如果里面大量出现尺寸图、安装图、配件清单图，那么你的图片顺序治理比图库控件的改造更紧急。

第五个数：客服工单里的那类问句

在工单和会话记录里搜一类句式：有没有安装以后的图、有没有别的角度、能不能发一张尺寸的图。这类问句的数量是本篇唯一一个能直接证明“图存在但没被找到”的证据。

操作也简单：把这类工单抽一批，逐条去对应的商品页上找那张图。找得到的那部分全是可见性问题，不是内容缺失。保哥的经验里这个比例通常高得让人意外，而它一直被当成用户问得多记在客服口径里。

把两个数交叉起来看

最容易读错的是右上那一格。图多而后段没人看，团队的第一反应几乎总是同一句话：看来用户不需要这么多图，精简一下吧。

这个结论方向正好反了。触达率低说的是他没能看到，不是他看到了不想要——这两件事在数据上长得一模一样，都是“后面那些图没有请求”。按前一种理解去做，你会把最能解答疑问的那批图删掉，然后过两个月发现客服问询涨了，而且找不到原因。

判别方法：把这批SKU里后段图片真正被请求到的那些会话单独拉出来，看它们的加购率跟站均比。如果明显更高，说明看到的人反应很好，那就是可见性问题；如果没差别，才轮到考虑内容本身。这一格的分析成本不高，但它决定了你接下来是修控件还是删素材，方向完全相反。

这五个数怎么串成一次汇报

五个数分开看都只是数字，串起来才是一条能被决策的链。顺序建议这么排。

先放第二个数那条曲线，因为台阶是所有材料里最不需要解释的一张图，投出来就有人问那道坎是怎么回事。接着放第四个数，说明这批图在数据文件里也被截掉了，把问题从前端扩展到全站。

然后放第五个数，客服工单里那些问句，它给整件事提供了人的证据——每一条工单背后都是一个具体的人在问一个页面上已经写着的东西。最后才放第一个数和第三个数，作为改造之后的衡量基线。

别一上来就讲触达率。它是个比值，比值需要基准，而这件事上没有公认基准，讲了会立刻掉进“多少算好”的讨论里，而那个讨论没有答案。

有一个数不建议花力气去算

常有人想算“用户平均看了几张图”。这个数听上去最贴题，实际上最没用。

原因是它把两拨行为完全不同的人平均掉了：一拨人看了1张就决定不要，另一拨人认真看完9张，平均下来是5张，而这个5不描述任何一个真实用户。更糟的是它对改造非常不敏感，你把后段触达率翻一倍，这个平均数可能只从4.2动到4.9，汇报的时候毫无说服力。

凡是遇到这种情况，办法都是同一个：放弃平均值，去看分布的形状。这也是第二个数比第一个数更值钱的原因。

这些数会跟别的报表打架，先说清楚口径

还有一件事要提前打招呼：日志算出来的图片请求数，跟前端埋点算出来的图片曝光数几乎不可能对得上，而这个差异会在跨部门汇报时被当成有人算错了。

差异来自四个方向，每一个都合理：浏览器缓存让重复访问不发请求，日志偏低；预加载让没被看到的图也发了请求，日志偏高；爬虫和监控的请求混在日志里，需要按用户代理过滤；埋点本身有丢失率，弱网环境下尤其明显。

处理办法不是去调平这两个数，而是在汇报的第一页就写明这个数是从哪儿来的、它偏高还是偏低、以及它只用来做什么比较。两套报表对同一件事给出不同数字并不可怕，可怕的是没人说清它们各自在测什么——这个坑在商品页那个推荐位两套报表算出相反的结论里已经完整踩过一遍。

另外提醒一句：弱网和低端机上，图片请求的失败率本身就是一个信号。如果某些市场的后段图片请求大量超时，那不是可见性问题而是交付问题，海外客户用低端机、弱网打开你的独立站有多卡那一套排查思路更对症。

改完之后哪些数会骗你，什么时候该停手？

一个灯具站两个月四个数全绿，第三个月被自己人撤销了一半。预警不是没响，是响成了一份真实的好消息。

实验设计的三个坑

第一个坑是分层。这类实验的结果必须按设备分开看，不能合起来算。原因在前面已经论证过：桌面用户的收益来自“从不知道到知道”，移动用户的收益来自“把滑动引到对的对象上”，两者的量级差好几倍。合并统计的结果通常是一个不显著的小正数，然后这个项目就被结掉了。

第二个坑是观察窗。图库是会变的，运营随时会补图、换主图、删过季的场景图。实验期内某一组的商品被补过图，这一组数据就脏了。开跑前先冻结一批SKU的图片，或至少留下变更记录，事后能剔除。

第三个坑是指标选择。把箭头做得更醒目，箭头的点击率一定会涨，这几乎是必然的。但这个数只证明了箭头被看见了，不证明用户拿到了他要的信息。真正该看的是后段图片的请求量，以及有多少会话走到了最后一张。

三条停手信号

第一条：后段触达率明显上去了，加购却一点没动。这时候该去看那几张图本身拍的是什么——如果第6张到第9张是同一个角度的四个色号，用户看到了也不会因此下单，问题在素材不在控件。

第二条：发现自己正在给一个平均只有3张图的品类做截断信号。这个品类没有这个问题，把力气挪走。

第三条：发现团队正在会上争论要不要在末位方块上标出还有几张。前面引过研究的结论，这一格没有证据支持任何一边。最容易吵三天的那个细节，恰好是研究说没差的那一个——这个信号很好用，它通常意味着真正有分歧的问题已经被绕过去了。

一个灯具站，两个月全绿，第三个月被自己人撤销了一半

一个做出海照明的独立站，吊灯、壁灯和户外庭院灯为主，卖美国、德国、法国，价格带60到400美元。这个品类的图天生就多，一个吊灯十来张是常态，尺寸标注和色温对比是决定买不买的两张。

照着本文的思路做了四周：桌面端把12张以内的商品全铺开不再截断，移动端末位露半张图，箭头描粗，商品数据文件补齐附加图片字段，后段图片补上描述性文件名和alt，结构化数据里把图片字段从1张改成全量。

两个月后四个数都好看：桌面后段触达率从31%涨到68%，请求断点曲线上第5张之后那道陡崖抹平成了斜坡，客服那类“有没有安装尺寸图”的问询降了约六成，图片搜索的展示量稳步上升。

第三个月，一次成功的性能优化

第三个月，前端做季度性能治理。图库全铺之后首屏要下载的图确实多了，于是他们把懒加载换成了自研实现：后段图片改为在用户滑动或点击缩略图条时才发起请求。

效果很实在。最大内容绘制从2.6秒降到1.9秒，页面初始字节数降了一大截，性能报告全绿。这次改动在评审里顺利通过，因为它确实是一次成功的性能优化，没有任何一个环节做错。

三个月后，图片搜索带来的落地次数掉了一半多，后段图片开始陆续从图片索引里消失。

为什么四层都没拦住

第一层，人肉验收全过。页面上人的那一侧一点问题都没有——用户会滑，滑了图就加载出来了。测试的人也一定会滑，不滑他没法验。人的通道完好，机器的通道断了，而两条通道共用同一段代码。

第二层，性能报告是绿的，而且是真绿。这里出现了一种以前没遇到过的预警形态：预警不是没响，也不是响错了，而是它以另一项指标变好的形式出现，而那份好消息是真的，并且它本身就是副作用。之前遇到过预警被读成捷报的情况，那是误读；这一次没有任何东西可以被误读，因为压根没有坏消息产生。

第三层，自然流量大盘还在涨，赶上了年底的旺季。

第四层最要命：Search Console的搜索类型默认显示网页，图片是另一个选项，要多点一次。一个通道的流量掉了一半，而看见它需要一次额外的点击。这里可以留下一条判据——损失不一定要分散在几十个小词上才会隐形，它也可以集中在一个通道里，只要那个通道的报表默认不打开。

怎么修的，以及流程里加了哪一条

改三处。第一处，懒加载改回视口触发，用IntersectionObserver，滑动和点击不再是加载的前提条件。第二处，把图库图补进图片站点地图，让机器有一条不依赖页面渲染的路径。第三处是流程，也是三条里最便宜最管用的一条。

新加的流程规则只有一句：任何改动图片加载方式的提交，必须附上一次前后对比——用curl拉页面源码，数里面有几个img的src指向商品图。而且这个数由提交改动的人自己跑，不转给做SEO的人。转给别人，它就又变成了两个部门各自持有一半信息的问题。

三个月后，图片搜索的流量回到了改造后的高点以上。

一个预期之外的发现

修好之后对比来源，从图片搜索进站的用户，加购率明显高于从站内列表页浏览进来的用户。

回头想想是合理的：图片搜索是唯一一种用户在点进来之前就已经看过商品长什么样的入口。他看到的那张图往往就是尺寸标注或者安装示意，也就是说，他要的那个答案在他到达你的页面之前就已经拿到了。这个入口自带一次预筛，把“看了图觉得不对”的那批人挡在了点击之前。

这也解释了为什么那批藏在第8位的图值得单独治理：它在页面上是一个可用性细节，在图片搜索里是一个完整的入口，而这两件事的价值不在一个量级。

如果重来一次

不需要更多的数据，也不需要更长的排期。只需要在那次性能优化的评审会上多问一句：这次改完之后，一个不会滑动、也不会点击的访客，还能不能拿到全部图片？

这句话五分钟就能验证，curl一次就有答案。它之所以没被问出来，不是因为难，是因为在那间会议室里，所有人心里的访客都是会滑动的。

这次的教训和以前几次不一样在哪

值得把它跟别的失手放在一起对比一下，因为预警的形态每次都不同，而形态决定了你该往哪儿看。

最后一行是这次的解法。当一次改动的副作用会以另一项指标变好的形式出现时，任何基于观察的监控都拦不住它——因为没有异常可以被观察到。唯一有效的做法是把“这一页里必须有9个商品图img”这句话变成一个断言，让它在每次构建时自动跑一遍。

那条curl数img的流程规则，本质上就是一个手工版本的断言。它之所以被要求由提交改动的人自己跑，是因为断言的价值在于它在改动发生的那一刻就报警，而不是三个月后由另一个部门发现。

这套做法在哪些品类上更容易踩坑

做完这一轮之后回头看，图多的品类不一定风险高，风险高的是图片数量在不同商品之间差异极大的品类。

灯具就是典型：一个简单的壁灯4张图讲完了，一个大型吊灯要14张。图库控件是同一套，截断位置固定在第6张，于是壁灯完全没问题、吊灯漏掉8张——而恰恰是吊灯客单价更高、决策更重。

如果做数据抽样时按SKU平均取样，这个问题会被稀释得几乎看不见。正确的抽样方式是按图片数量分层，把图片数量最多的那10%的SKU单独拉出来看，它们贡献的营收占比通常远高于10%。

换个平台，这套东西还成立吗

会有人问，用的是现成的电商主题，图库控件不是自己写的，这一整套还用得上吗。答案是用得上，只是入手点换了。

主题自带的图库通常有两三个可配置项：默认显示几张、要不要箭头、移动端用点还是用缩略图。先去后台把这几个开关翻一遍，很多站的问题在配置项里就能解决，根本不需要改代码。翻完之后再用前面那三条验收标准测一次，看还剩什么没解决。

剩下的部分才需要动模板。这里有一个平台差异要注意：不同平台对模板的开放程度差很多，有些元素是被锁死的，改不了就得绕。哪些能改、哪些改不了，Shopify的页面元素哪些能改、哪些被平台锁死里有一份对照，图片这一侧的平台化清单则在Shopify图片SEO从命名到压缩的完整清单里。

还有一个更省力的判断：如果你的站用的是市面上常见的主题，那么同一个截断问题大概率也存在于你的竞品站上。这既是坏消息也是好消息——坏在没人替你验证过更好的做法，好在做完之后你会是那个品类里少数几个不漏图的站。

常见问题解答

商品页图库默认该露出几张缩略图？

桌面端如果单品图片数量的中位数在10到14张以内，最省事的答案是全部铺开、不做截断，Baymard的测试结论是桌面用户浏览缩略图没有困难，哪怕排成两行。超过这个量再考虑截断加信号。移动端竖屏宽度有限，全铺不现实，那就保留一条缩略图带、末位露出半张图，或者两端加箭头。真正要定的不是一个通用数字，而是三件事：图片数量分布是什么样、被截掉的那批图承担什么信息、截断之后有没有任何视觉元素告诉用户还有更多。前两件查一下数据库和客服工单就有答案，第三件把窗口拖窄看一眼就知道。

移动端用小圆点代替缩略图，到底行不行？

行，但有两个前提。第一个是命中区尺寸要过线。WCAG 2.2的成功准则2.5.8要求指针目标至少24乘24 CSS像素，达不到就得走间距例外——以每个圆点的包围盒为圆心画直径24像素的圆，这些圆不能相交。常见的8像素直径、8像素间隔排布过不了，把间距拉开通常只要改一个gap值。第二个前提是滑动手势必须可靠。Baymard的观察是用户几乎只在滑动失灵时才去点圆点，而备用方案被启用的时刻，正是主方案已经出问题的时刻。

缩略图被容器裁掉，会不会影响图片被Google收录？

取决于图片是怎么进入页面的，跟视觉上有没有被裁掉关系不大。Google图片的文档写明只索引img元素src属性里的图片，CSS背景图不索引。所以图片全都写在初始HTML的img标签里、只是被容器裁齐的话，抓取程序照样拿得到。真正会出事的是另一种实现：后段图片要等用户滑动或点击才注入DOM。Google明确说过它不会与页面交互，所以这批图对它等于不存在。判断方法很直接：用curl拉一次页面源码，数里面有几个img的src指向商品图，跟后台上传的张数对一下，差多少就是机器拿不到的那部分。

overflow写hidden和写clip，差别有多大？

视觉上完全没差别，两种写法渲染出来的画面一模一样，页面截图对比不出来。差别在键盘可达性上。用hidden时它仍是滚动容器，用户虽然不能用滚轮或拖动滚它，但Tab键把焦点移到被裁掉的元素上时，浏览器会把它滚进视口，脚本也能设置滚动位置。用clip时它不是滚动容器，焦点走进去了画面却不动，MDN的原话是这会让那部分内容对键盘用户不可访问，程序也滚不了。这一个单词的差别在设计评审里永远看不出来，只能靠按Tab键测。

图库里的图要不要全部写进结构化数据和商品数据文件？

结构化数据建议全写，成本几乎为零，它是搜索引擎挑选展示缩略图时参考的元数据之一。商品数据文件有硬上限：主图字段一张，附加图片字段最多10张，加起来11张，超出的部分会被截掉。所以这里要做的不是全写，是排序。四个通道的截断方向是一致的，都从尾部砍，而运营上传图片的顺序通常是拍摄交付顺序，白底图先到、尺寸标注和安装示意最后到，结果被砍掉的恰好是回答用户犹豫的那批图。把最容易引起疑问的那张放到第2或第3位，这一个动作对页面、数据文件、结构化数据和用户耐心同时生效，是这件事上性价比最高的一步。

图库用了懒加载，会不会让图片不被索引？

正确实现的懒加载不会。Google认可三种做法：浏览器内置的图片和iframe懒加载、IntersectionObserver加polyfill、以及支持元素进入视口时加载的JS库。共同点是触发条件为进入视口，而不是用户做了什么。会出事的是自研成滑动或点击才请求的实现，官方文档特意点名说这类做法不行，理由是搜索不会与页面交互。另外有一条反向提醒：别给打开页面就立刻可见的内容加懒加载，那会让首屏变慢，主图通常属于这一类。判断自己站上属于哪一种，看代码最快。

不加埋点，怎么判断用户漏看了商品图？

用访问日志。每张商品图被看到都对应一次真实的文件请求，这件事你已经记录很多年了。第一个数是后段触达率：某个SKU第6张及之后的图片请求总数，除以第1张的请求数，按设备类型分开算。第二个数更有信息量：把每次会话请求到第几张就停了画成衰减曲线，看它是斜坡还是台阶——兴趣衰减是平滑的，设计造成的截断会在默认展示张数那里留下一道陡崖。这条判据不需要任何基准值，只看形状。有一个口径坑要记住：浏览器缓存会让重复访问不发请求，所以这个数天然偏低，只能横向比较，不能当成绝对百分比去汇报。

权威参考资料