类目导航改版做了三轮，用户点进来的那一屏，仍然没有一个字写着他在哪

摘要：把导航做坏的不是菜单层级太深，是没有任何一段代码知道用户此刻正在看哪一批商品。这个东西在网址里被存了成千上万份，在屏幕上一份都没有——同一个变量，机器那侧过剩到拖垮抓取预算，人那侧是赤字。

导航的失分，集中在一个代码里根本不存在的变量上

先摆数字。一家专做电商可用性研究的机构在2025年做完了一轮首页与类目导航的横向评测，样本是美欧180多个头部电商站，人工评分条目16000多项。结论一句话：桌面端58%、移动端67% 的站，这块体验落在“中等到差”这一档。更难看的是另一句——整份榜单里没有一个站在这个主题上拿到“优秀”。

这份评测把41条导航准则里的11条摊开来讲了不达标率。我把这11个数字抄在下面，你先别急着看结论，就当是一份体检报告的化验单。

十一项里最高的两项，都不是“点不动”

95% 和76%，一个是不高亮当前位置，一个是中间层类目页把子类目埋了。这两件事有个共同点，值得停下来想一会儿：它们都不影响用户点得动点不动。链接是好的，页面是通的，服务器返回200，前端不报错，自动化测试全绿。

反过来看那几项低的。33% 是标题不可点击，32% 是轮播实现不对。这两件事恰恰是能被查出来的——标题是不是包在链接标签里，一条选择器就扫完了；轮播多少秒换一屏，配置文件里写着。

顺着这条线往下数，11项能干净地劈成两堆。

一堆能用脚本查，一堆只能用眼睛看

能用脚本查的意思是：不需要任何用户、不需要任何工具采买、不需要任何预算，你自己写二十行代码在自己站上跑一遍就能知道答案。按这个标准，11项里有4项属于这一堆。

45.0% 对66.7%，差21.7个百分点。这个切分是我自己算的，原报告没这么分过。它说明的事情很朴素：凡是能被一段代码断言的缺陷，这个行业已经做得明显更好；剩下的失分，集中在没有任何自动检查能碰到的地方。

但这还只是表层。真正的问题是——为什么这几项就是没法被代码查？不是技术不够，是要查的那个东西，在系统里压根没有一个变量装着它。

把这个东西叫做“范围”

用一句话定义：范围，就是用户此刻相信自己正在看的那一批商品。

注意“相信”这两个字。它不是数据库里的商品集合，是用户脑子里那句话。他现在如果被人拍一下肩膀问“你在看啥”，脱口而出的那句就是范围：

• “我在看女装里的连衣裙。”
• “我在看这个牌子所有打折的鞋。”
• “我在看能寄到我们州的、五十美元以下的猫粮。”

这三句都不长，都能说出口。麻烦的是第三句里的“能寄到我们州”和“五十美元以下”——这两个条件是他自己刚才点出来的，页面记住了没有？记住了有没有告诉他？他要是忘了自己点过，页面帮他回忆得起来吗？

再回头看那11项。一项一项对：

• 移动端首页那个方块写着“新品”，点进去其实是“女装 > 新品”——范围被写窄了但没说；
• 主导航不高亮当前位置——范围没告诉他；
• 中间层类目页把子类目埋在促销位下面——范围没法继续收窄；
• 子类目一口气列三十个——一次要在太多范围里选一个；
• 灵感图上那八件商品点进去落到全类目列表——图片建立的那个极窄范围，一点就没了；
• 可点区域边界不清——他不知道点下去范围会变成什么。

十一项里有九项能被同一句话概括：界面没有把范围保管好。

为什么说它是“代码里不存在的变量”

你去翻任何一个电商前端的代码库，能找到 categoryId、filters、sortBy、page，能找到路由参数、查询参数、状态管理里的一堆字段。这些都是范围的零件。

但你几乎找不到一个东西，它的职责是“把这些零件拼成用户能读懂的那一句话，并保证这句话在每一屏上都可见、都一致、都跟得上变化”。

这活儿没有主人。后端知道 categoryId 是4471，不知道它对外该叫“连衣裙”还是“裙装”；导航组件拿到一棵菜单树，不知道当前请求落在树的哪个节点上；面包屑组件知道路径，不知道用户还叠了三个筛选条件；筛选组件知道叠了哪三个，但它长在页面中段，用户滚下去之后它就不在视野里了。

每个零件都有主人，拼起来那句话没有。于是它被默认交给了用户自己记。

一个用户必须一直记着的东西，如果代码里没有一个变量装它，那就是用户在替系统保存状态。而用户保存状态的方式是记忆，记忆的失败形态叫“以为”。

“以为”这两个字很关键，它决定了这类失败为什么查不出来。用户不会报错，不会点两次，不会触发任何告警。他只是基于一个错误的范围做了判断，然后关掉了页面。原报告里有个测试片段特别典型：一位受访者在某服装站首页点了“五折”的广告位，看到的商品里混着外套，她以为这就是这家店女装的全部，说了句“这些裙子都不太行，我回首页看看”，然后就走了。她不是不喜欢那家店的裙子，她根本没看到那家店的裙子。

为什么“改导航”这件事总是做完像没做

把范围这层意思摆出来之后，有个长期让人费解的现象立刻就通了：导航改版的投入产出比，在多数团队的记忆里是偏低的。

你回忆一下自己经历过的导航改版都在改什么。层级从三级压成两级，或者从两级撑到三级；一级类目从十二个减到八个；巨型下拉换成分栏式；移动端汉堡菜单换成底部标签栏；类目名统一了一遍措辞。这些动作有一个共性——改的全是那棵树的形状。

树的形状确实要紧，但它管的是“用户能不能走到那儿”。而11项里失分最重的那几项管的是另一件事：他走到了，知不知道自己走到了哪儿。树改得再漂亮，这件事一个字都没动，改版之后当然摸不着什么变化。

更别扭的是，这两件事的成本差着量级。改树形要动商品运营、动数据回填、动跳转规则、动搜索引擎那边的收录，是一次跨部门的大工程；而把当前范围说出来，多数情况下是给导航组件加一个参数、给页面顶部加一行字。贵的那件被反复做，便宜的那件一次没做过。

先说清楚这篇文章不打算解决什么

范围保管不是万能钥匙，有三件事它治不了，先摆在前面免得读到后面失望。

• 类目树本身分错了，它治不了。把“户外”和“运动”切成两棵互不相干的树，跑鞋放哪边都别扭，这是商品运营的活儿，跟前端怎么显示当前位置无关。
• 商品本身不够，它治不了。用户能一眼看清自己在“男士跑鞋42码”这个范围里，然后发现这个范围里只有三双，该走还是走。
• 它不保证短期数字好看。这一条后面会展开讲，把范围说清楚会让一部分人提前发现“这儿没我要的”，类目页的跳出率反而会往上走一点。

这一整篇文章讲的都是同一件事：范围归谁保管，怎么判断保管得好不好，无障碍与合规那边的规范在这件事上说了什么、又漏了什么，怎么不埋点也能把它量出来，以及怎么在不需要改变任何人观念的前提下把它焊进流程。

范围会出问题的四种方式

把11项再切一刀，这次按“范围是怎么坏掉的”分。坏法只有四种，而且四种的解法方向完全不同——分不清就会互相抵消。

四种里，第一种和第二种最容易被混为一谈，而它们的解法是反着的。范围没说，缺的是信息，加就完事；范围说错，缺的是一致性，加信息反而会让事情更糟——你在一个本来就写着“新品”的按钮旁边再加一行“精选好物”，用户对这个入口通向何处的猜测更混乱了。第二种要做的是删和改，不是加。

第四种最难，因为它是唯一一个失败发生在用户注意力之外的。前三种至少发生在他正盯着看的那一屏上；第四种发生在他刚点完某个按钮、视线正在移动的那半秒里。他不会觉得“页面骗了我”，只会觉得“这家店的东西有点乱”。

把这四种坏法对着自己的站过一遍

这张表可以直接当自查表用，每一行给一个具体的落地问句：

• 没说：随便打开三个类目页，首屏里有没有一处原样写着当前类目名？
• 说错：首页和活动页上所有通向商品列表的入口，文案里的词跟它真正落到的那个范围对得上吗？特别注意那些只写了促销语的方块。
• 收不窄：中间层类目页上，子类目的第一个入口在第几屏？超过第一屏就算不达标。
• 被改了：在类目页里点一次顶部导航的另一项，已选的筛选条件是保留、清空还是部分保留？页面有没有说？

四个问句，一个站十分钟能过完。本文这份对11项的重新分类和后面所有推论，用的原始评分数据来自首页与类目导航的2025年横向评测，样本与口径可自行核对；但那份评测本身是按“最佳实践条目”平铺的，没有做过这种按失效方式的归并——归并之后能看出的东西，比逐条罗列多得多。

用户脑子里那句话是什么，屏幕上写了没有？

判断一个页面有没有把范围保管好，不需要工具，不需要用户测试，也不需要读完这篇文章。三句话，顺着问下去就行。

第一句：他现在能不能一句话说出自己在看什么

把自己放到用户的位置上，看着这一屏，试着补完这个句子：“我现在看到的是____里的商品。”

补不出来，或者补出来一句自己都心虚的话（“应该是……女装吧？或者是打折的？”），那就是范围没建立起来。补得出来但是要靠推理（看到左上角有个“L”的图标，猜这是女装区），那也不算——推理成本就是失败成本，只是它被摊薄在每一屏上，看不出来而已。

这一问最容易在两个地方翻车。一个是从站外直接落地的页面：搜索结果点进来、广告点进来、社交媒体点进来的人，脑子里没有任何上文，全靠这一屏。另一个是叠了筛选之后的列表页——用户点了四五个条件，滚到第三屏，此刻还记得自己点过什么的比例远比你想的低，这件事在集合页连点五个筛选之后用户会忘掉自己选过什么那篇里单独拆过。

第二句：这句话有没有原样写在屏幕上

注意“原样”两个字。不是“能推断出来”，是那几个字就明明白白印在那儿。

这一问会淘汰掉大量自我感觉良好的实现。常见的自我安慰有这么几种：

• “我们有面包屑啊”——面包屑写的是树上的路径，不含筛选条件，这个区别下一节专门讲；
• “页面标题里有啊”——浏览器标签页那一行用户不看，页面上的 h1 常常被设计成了一张促销图；
• “左侧筛选栏里勾选框是选中状态啊”——那是控件的状态，不是一句话，而且滚出视野就没了；
• “网址里有啊”——用户不读网址，机器读。这两侧的分工后面会算一笔账。

合格的样子长什么样？大概是这种：页面顶部一行，写着“女装 > 连衣裙 · 黑色 · 100元以下，共128件”，跟着列表一起吸顶，改一个条件这行字立刻跟着变。就这么朴素。它的价值不在设计上，在于它是整页唯一一个“我知道你在看什么”的表态。

第三句：下一步动作会把这句话改成什么，改完他看得见吗

前两句问的是静态的此刻，第三句问的是变化。而三句里最狠的是这一句。

原因很实在：前两句的问题用户看得见，也抱怨得出来。“我不知道自己在哪儿”是一句人话，用户访谈里会说，客服工单里会写。第三句的问题用户连抱怨都不知道从何抱怨——因为范围是在他没注意的时候被悄悄改掉的。

举几个真会发生的：

• 他在“女装 > 连衣裙”里勾了“黑色”，然后点了顶部导航的“新品”。现在他在“全站新品”还是“女装新品”还是“女装连衣裙新品且黑色”？三种实现都有人做，页面上通常不说。
• 他在类目页把排序从“推荐”改成“价格从低到高”，某些站会顺手把分页重置到第一页——这个对；某些站会连筛选一起清掉——这个不对，而且不说。
• 他从商品详情页点了面包屑上的“连衣裙”回到列表，之前勾的“黑色”还在不在？大部分站不在。用户以为自己是“回去”，实际是“重新开始”。
• 他切换了配送地址或者站点语言，可售商品集合变了，列表条数从128变成76，页面一个字没说。

这四种的共同点：屏幕上的商品确实换了一批，而用户脑子里那句话没换。接下来他做的每一个判断——这家店款式少、这家店价格高、这家店没有我要的尺码——都建立在一个已经不成立的前提上。

这跟另一件事的结构非常像：用户在结账页回头改一个已经填过的字段，前面定好的运费、送达日期、可用支付方式跟着变，页面同样什么都不说，那篇是结账流程里首填与返工两条路。两处的失败形态一模一样：状态变了，持有状态的那个人不知道。

五分钟就能做完的验收动作

三句判据可以直接变成一套动作。保哥这几年在不同站上做过十几回，流程固定，五分钟出结果，不需要任何工具。

1. 开一个全新的无痕窗口，不许从首页进——直接把一个第三层类目页的网址粘进去回车。这一步模拟的是搜索和广告流量，也就是多数站占比最大的那批人。
2. 不滚动，就看首屏。把那句“我现在看到的是____里的商品”补完。补不出来记一笔。
3. 把窗口宽度拖到手机尺寸，同一个页面再来一次。多数站在这一步会掉一大截，因为桌面端那点当前位置的痕迹（导航条上的颜色变化）在移动端根本没有导航条。
4. 加一个筛选条件，比如颜色选黑色。看那句话变了没有，页面有没有在任何地方说出这个新条件。
5. 点一个商品进详情页，再用面包屑退回来。看刚才那个筛选条件还在不在，以及在不在这件事页面说了没有。

做完顺手截三张图：桌面首屏、移动首屏、加筛选之后。三张图并排放，不需要任何解说词。这是这个动作最值钱的地方——你没法跟人争论“用户会迷路”，因为这是个概率判断，对方永远可以说“我们的用户不会”；但你没法否认“这一屏上没有任何一处写着当前类目的名字”，因为这是个事实判断，图就在那儿。

这个动作为什么不能交给工具跑

肯定有人会问：这么机械的检查，写个爬虫扫全站不就完了？

能扫的部分确实能扫，但扫得出来的是最不重要的那部分。工具能查aria-current属性有没有、导航项有没有加高亮类名、页面上有没有面包屑结构化数据。这些查的都是“有没有这个零件”。

工具查不出来的是“这句话对不对”：

• 高亮加在了“女装”上，可用户是从男鞋点进来的——属性对，内容错；
• 面包屑写着“首页 > 女装 > 连衣裙”，可用户还叠了三个筛选——结构对，信息不全；
• 顶部那行字确实存在，但它是服务端渲染时算的，用户点了筛选之后走客户端更新，那行字没跟着变——首屏对，后续错；
• 字都对，但它用的是内部叫法“女士针织连身”，用户点的按钮上写的是“连衣裙”——都对，对不上。

最后这一条特别常见，也特别隐蔽。它属于同一个概念在不同页面上叫了不同名字这一类问题，本质是字段没对齐，在商品比较里字段对齐与披露分层那篇里有完整的拆法。凡是需要判断“内容对不对”的检查，都只能靠人；工具能做的是把“零件缺没缺”筛一遍，把人力省下来用在判断上。

三句判据摊开来对比

三句话看着像一个递进，其实它们在每一个维度上都不一样。摊开对比一次，后面派活的时候能少扯不少皮。

最后一行是这张表最实用的地方。第三句对应的改动做完之后，页面在截图上几乎没有变化——它只在用户做了某个动作之后才显形。这意味着它天然缺少可展示的成果，在争取资源时结构性吃亏。要提前想好怎么证明它做完了，最省事的办法是录一段十几秒的操作屏录：改一个条件，那行字跟着变，配套的件数跟着变。

这三句判据不只对电商类目页有效

换个场景验一下，能看出它是不是真的抓到了共性：

• 后台的数据列表页。运营筛了时间范围、渠道、状态三个条件，导出一份表，第二天打开这份表想不起来当时筛的是什么——同一个毛病，只是这次受害者是自己人。
• 协作工具里的视图。你分享一个筛选后的任务列表链接给同事，他打开看到的是全部任务还是你筛过的？多数工具这件事做得比电商站好，因为它们的用户会当场投诉。
• 搜索结果页。用户搜了一个词，页面顶部通常会写“关于某某的128条结果”——这恰恰是范围保管做得最标准的一个例子，而且几乎所有站都做对了。有意思的是，同一个团队做的类目页却什么都不写。

最后这条对照特别有说服力，可以直接拿去开会用：搜索结果页你写了“关于某某的128条结果”，类目页凭什么不写？两者本质是同一件事——都是“一批被条件框定的商品”，只是一个的条件来自输入框，一个的条件来自点击。

答案通常也很朴素：搜索结果页那句话是搜索组件自带的默认输出，类目页的模板里没有这么一个自带默认输出的东西。不是谁做了决定，是一边有默认值、一边没有。

95% 这一项为什么在一年里反而变差了？

整份评测里有一个数字值得单独拎出来：不高亮当前位置这一项，2024年是91%，2025年是95%。其余各项要么持平要么略有改善，只有它在倒退。

一个行业在一年里集体把一件事做得更差，通常不是因为大家变懒了，而是因为某个正在被广泛推行的做法，顺手把它挤掉了。这一节想把这个挤掉的过程讲清楚，因为它同时解释了另外几件长期讲不通的事。

导航从“页面的一部分”变成了“与页面无关的一份数据”

十几年前的模板长什么样？导航那一段是写在页面模板里的，渲染这个页面的时候顺手带上当前类目的编号，哪一项该加高亮类名，就在那儿判断一下。当前位置这件事是免费的——渲染上下文里本来就有它，不用它才需要额外解释。

现在的做法是这样：导航是一个独立组件，它的输入是一棵菜单树。这棵树从内容管理后台或者商品目录接口取，跟这次是谁在请求、请求的是哪个页面完全无关。组件负责把树画成一个巨型下拉或者一个抽屉，把“树”这件事做得很好。

问题在于，当前位置不是树的属性，是“这次请求”的属性。它属于路由那一侧，而导航组件在架构上被刻意设计成不关心路由——这正是它能被复用、能被缓存、能被独立测试的原因。

于是这条信息掉进了缝里：路由知道当前在哪，但它不认识菜单树；导航组件认识菜单树，但按设计它不该知道当前在哪。两边都没做错，中间那条线没有主人。

静态化的方向，天然排斥那唯一一格因人而异的东西

第二层原因比组件化更硬，也更少被说出来。

这几年前端性能优化的主线是什么？把页面尽量变成静态产物，推到边缘节点上，让请求不落到源站。整站预渲染、增量静态再生、边缘缓存整页HTML，方向都是一个：同一份HTML发给所有人。

而“当前位置高亮”是导航里唯一一个会让HTML因请求而异的东西。类目页A和类目页B的导航条，除了高亮那一格，一模一样。你要做高亮，这两个页面的导航区就不是同一份字节了。

这件事在缓存策略讨论里几乎不会被提起，因为它太小了——小到没人会为它专门开个议题。它是被顺手放弃的：整页缓存方案定下来，导航区抽成公共片段，一切正常，谁也没意识到刚才那一格没了。一年后评测报告出来，91% 变成95%。

顺带说一句，这个取舍并非只在导航上出现。预渲染与预取让站内翻页秒开那套机制、以及各种把页面推到边缘的做法，本质上都在做同一笔交易：用“这一份内容对所有人都一样”换速度。交易本身没错，错在没人清点过换出去的都是什么。

不是不能做，是没人把它当成一条需求提

要澄清一件事：范围高亮跟静态化并不是不可调和的。三种做法都能在保住整页缓存的前提下把它做出来，成本都很低。

• 页面根节点打标记，导航靠选择器自己认。服务端在body上写一个当前类目路径的属性，导航项各自带着自己的路径，样式层用属性选择器匹配上就高亮。代价几乎为零：导航区仍是同一份字节，只有body那一个属性因页面而异，整页缓存该怎么切还怎么切。
• 用结构选择器就地判断。现代浏览器支持的父级选择器可以让导航容器根据内部某个子项的标记状态改变样式，服务端完全不参与。前提是那个标记本身存在，另外要看目标用户的浏览器版本够不够新。
• 客户端补。页面加载完之后读一下当前路径，给匹配的导航项加类名和无障碍属性。最省事，但首屏那一瞬间是没有高亮的，如果你的验收方式是截首屏，这一种会被判成没做。

第一种最实用，写出来大概就这么几行：

<!-- 服务端渲染时只需在根节点写一个属性 -->
<body data-scope="women/dresses">

<!-- 导航项本身是完全静态的、可缓存的 -->
<a href="/women" data-path="women">女装</a>
<a href="/women/dresses" data-path="women/dresses">连衣裙</a>

/* 样式层自己匹配，导航区字节零变化 */
body[data-scope^="women"] a[data-path="women"] { ... }

真正的障碍从来不是技术。是这件事从来没有以一条需求的形式出现在任何一张单子上。产品经理写需求写的是“主导航支持三级类目”，设计给的稿是导航的默认态，前端按稿实现，测试按稿验收。当前态既不在需求里，也不在稿里，也不在用例里——四道工序全部通过，而它从头到尾没被任何一道碰到过。

这条机制顺带解释的另外三件事

第一，为什么高亮在预发环境里“明明是好的”。预发环境通常不开边缘缓存，或者缓存策略跟线上不同。开发本地跑的是完整服务端渲染，一切正常；线上走缓存，那一格没了。这类问题在提测环节抓不到，因为提测环境和生产环境在这件事上根本不是同一套东西。

第二，为什么移动端比桌面端差得更明显。桌面端导航条常驻，高亮那一格哪怕做得很弱（换个字色）也在视野里。移动端导航藏在抽屉里，用户不主动打开就永远看不到——就算你做了高亮，它也不在屏幕上。移动端要说清范围，只能在页面正文区域另找地方，而这件事需要的不是给导航组件加参数，是给页面模板加一个新区块，成本立刻上一个台阶。这也是为什么移动端67% 比桌面端58% 更难看。同一类落差在移动应用上更极端，同一个搜索框在移动网页和应用里的达标率差了七倍那篇拆过一次容器默认值的账。

第三，为什么这一项特别容易在改版中丢失。它是一个“态”，不是一个“元素”。改版时组件对着组件迁移，元素清单能对得上，态对不上——因为没有一张清单列过态。首页信息架构那类改造尤其容易出这个事：整套导航重写一遍，视觉上更统一了，当前态在新组件里没有对应实现，而没有任何一条验收会发现它。

一件本来免费的事，在架构演进中变成了要额外花钱的事，通常没有人会在那一刻记账；账要等到一年后的横向评测里才出现，而那时已经没人记得它是什么时候没的。

四道工序，没有一道会碰到“当前态”

组件化和静态化解释了它是怎么丢的，还差一层：为什么丢了之后没有任何一个环节把它捡回来。把研发流水线摊开看，答案很直白。

四道工序全部通过，质量报告全绿，而那一格从头到尾没被任何一道碰到过。这不是谁偷懒，是整条流水线的输入输出里根本不含这个概念。

顺着这个看，还能解释一个很常见的现象：为什么这类问题在设计走查里也发现不了。走查是拿实现出来的页面对着稿看，一处一处比。而稿上没有当前态，所以“实现和稿一致”这个结论是成立的——它一致地都没有。

把“态”单独列一张清单

治本的做法不是在每个环节加检查，是补一份从来没人做过的交付物：态清单。

规则很简单：任何一个会随请求或用户操作改变外观的组件，除了默认态之外，把它所有的态列出来，每个态给一句话说明什么时候出现。以主导航为例：

• 默认态：用户在首页或不属于任何类目的页面上；
• 当前态：用户所在页面属于某个类目，该类目所在的那一项要与众不同；
• 展开态：某一项被悬停或点击后，其子级面板可见；
• 当前 + 展开：用户展开的正好是他所在的那一项，这时两种视觉处理会叠加，得确认叠加后仍分得清；
• 禁用态：某个类目暂时下线但仍需占位；
• 加载态：类目树尚未取到时导航长什么样。

六个态里，多数团队只交付了两三个。列这张清单花不了一小时，但它有个很好的性质：它是一份可以被逐条打勾的交付物，而打勾这种检查是最容易被排进流程的。你不需要说服谁“当前态很重要”，只需要让它出现在一份必须填满的表格里。

这也是本文后面那条卡点建议的雏形——先让它成为一个必须被回答的问题，至于回答得好不好，那是下一步的事。

面包屑都做了，为什么用户还是不知道自己在哪？

面包屑是这件事上最常见的挡箭牌。“我们有面包屑”这句话在评审会上出现的频率，大概仅次于“这个我们后面会优化”。

面包屑当然是好东西，但它回答的问题和范围这个问题只有一部分重叠。把这个重叠区画清楚，很多争论就不用吵了。

面包屑写的是树上的路径，不是这批商品怎么来的

面包屑的定义很干净：当前页面在站点层级里的祖先链。首页 > 女装 > 连衣裙，三个节点，一条路径，来自类目树。

范围是另一回事。用户此刻看到的这批商品，是由这些东西共同决定的：

• 类目路径（面包屑管这一段）；
• 用户勾选的筛选条件（颜色、尺码、价格区间、品牌、材质……）；
• 排序方式（虽然不改变集合，但改变了他看到的前二十件是哪些）；
• 分页位置（他现在在第4页，第4页的商品和第1页完全不同）；
• 用户所在地区决定的可售集合（跨境站尤其明显）；
• 库存过滤（很多站默认隐藏无货商品，而这个默认值从来不显示）。

六项里面包屑只覆盖第一项。用户在左侧栏勾了五个条件，面包屑一个字都不会变。这就是那句“我们有面包屑”最大的漏洞——它是一个正确的回答，回答的却是另一个问题。

顺带说，面包屑本身也有一堆没做对的实现，类型、层级取舍、结构化标记怎么配，另有一整套讲究，那是面包屑的几种类型与结构化数据落地那篇的范围，这里不重复。

同一个范围，在网址那一侧被存了成千上万份

现在把镜头转到机器那一侧，你会看到一个非常刺眼的对比。

范围在屏幕上一份都没有，在网址里却多到成灾。用户勾五个筛选条件，多数电商前端的做法是把它们拼进查询参数，于是每一种组合都是一个独立的地址。三个颜色、五个尺码、四个价格区间、六个品牌，光这四个维度的组合就是好几百个地址，再叠上排序和分页，一个类目轻松产出几万个。

这就是分面导航那套老大难，它怎么吃掉抓取预算、怎么造出海量近似页面、该用哪几种手段收口，分面导航的抓取预算与索引治理和筛选参数造出的抓取陷阱两篇拆得比较细。这里只取一个角度：

同一个变量，在机器那一侧过剩到需要专门治理，在人那一侧是彻底的赤字。范围不是没被存下来，是只存给了不需要它的那一方。

这句话值得多想一会儿。爬虫不需要知道“你在哪”——它没有连续的浏览过程，每个地址对它都是独立的一次抓取。需要连续感的是人，而人这一侧一个字节都没存。

搜索引擎的建议和用户的需要，在同一个变量上要求相反

更有意思的是，这两侧的最优解有时候是直接冲突的，而且冲突得很干净。

搜索引擎官方讲分面导航网址抓取管理的那份文档里给过一条建议：把筛选条件放进网址的片段标识符里（就是井号后面那一段）。理由是爬虫通常不处理片段，筛选组合再多也不会产生新的可抓地址，抓取预算的问题当场消失。

从抓取角度看这是最干净的解法。从范围保管角度看这是最糟的解法。片段不会发到服务端，服务端渲染那一刻并不知道用户筛了什么，那句“你现在看的是黑色的连衣裙”只能等页面加载完由客户端补上——而首屏那一瞬间，它不存在。

同理，站内的锚点跳转也活在片段这一侧，这套机制本身有它的用武之地，页内导航与锚点片段那篇讲的是它擅长的场景；但把决定“看到哪批商品”的条件也塞进去，就等于主动把范围从服务端赶走。

还有几条官方建议同样值得抄下来，因为它们全都指向同一个道理——一个地址必须稳定地代表同一个范围：

• 参数分隔符老老实实用与号。逗号、分号、方括号这些，爬虫认不出它们是分隔符，因为绝大多数情况下它们确实不是。
• 把筛选编进路径的，顺序必须恒定，且不许出现重复条件。同样三个条件换个顺序就是另一个地址，那这个地址就不再唯一代表一个范围了。
• 筛选组合查不到东西时，就在那个地址上返回404，不要跳到统一的错误页。这一条最容易做错，也最能说明问题。

空结果那一屏，恰恰是范围最需要被说清楚的时候

最后那条建议值得展开。为什么“跳到统一错误页”是错的？

因为“这个范围里没有商品”本身就是关于这个范围的一条真实信息。用户勾了“绿色 + 42码 + 100元以下”，结果是空的，这条信息对他极其有用：他知道了要放弃哪个条件。你把他丢到一个通用的“页面不存在”，等于把这条信息抹掉，还顺带告诉他“你刚才那一串操作是非法的”。

好的空结果页长什么样，其实就是范围保管做到位的样子：

• 那句话还在——“女装 > 连衣裙 · 绿色 · 42码 · 100元以下，0件”；
• 每个条件后面带一个去掉它的入口，并且写清楚去掉之后剩几件（“去掉价格限制 → 17件”）；
• 不清空用户已选的一切然后甩他回全类目，那是把范围直接销毁。

顺便，这一屏也是范围这件事上唯一一个用户会主动抱怨的场景。平时他不知道自己丢了范围，只有在这一刻，他明确知道“我筛出来的东西不见了”。所以空结果页的处理方式，基本可以当成一个站范围保管水平的探针。

范围要存两份，且必须一致

把两侧合起来，可以给出这一节的结论。

两份必须一致，这一点在做规范网址判定时尤其要命。你把带筛选的地址全都指向不带筛选的版本，机器那侧干净了，但用户从搜索结果点进来落在不带筛选的页面上，看到的商品跟他搜的那个具体需求对不上——规范网址是个提示不是命令，而且它解决的是重复问题，不解决“用户落错范围”这个问题，这两件事经常被混着谈，规范标签的常见误用那篇把边界划得比较清楚。

还有一个更实际的判断：哪些筛选组合值得拥有自己的地址、自己的标题、自己的那一行范围描述？判据不是“技术上能不能”，是“有没有人会用这句话去搜”。“黑色连衣裙”有人搜，“黑色 + 42码 + 周三上架”没人搜。前者值得做成一个真正的落地页，后者就该老老实实待在片段里或者被挡在索引外。这条判据同时管住了两侧：列表页与集合页的机制那篇是从收录侧讲的，而从用户侧看，它决定的是哪些范围值得被写成一句话。

哪些范围值得拥有一个自己的地址

前面说到“有没有人会用这句话去搜”是判据，这里给个更好用的三问版本。一个筛选组合要不要拥有独立地址、独立标题、独立的那一行范围描述，顺着问：

1. 有没有人会用这句话去搜？“黑色连衣裙”有，“黑色加42码加周三上架”没有。
2. 这个组合下的商品数量稳不稳定？常年只有零到三件的组合不值得做成落地页，它今天有明天没有，做出来就是个坏页面制造机。
3. 这个组合能不能用一句人话说出来？说不出口的组合，说明它不是一个概念，只是几个开关的偶然叠加。

三问全过的，值得给它一个干净的路径式地址、一句写死的范围描述、一段自己的类目文案。三问过不了的，老实待在参数或者片段里，别进索引。

这条判断的价值在于它同时约束了两侧：机器那侧知道该收哪些、挡哪些，人那侧知道哪些范围值得被认真写一句话。以往这两件事分别由做技术优化的和做体验的各判一次，判据不同，结果自然对不上。

六种范围来源，各自存在哪儿、用户看不看得见

最后两行是最狠的：它们决定了用户看到什么，却从不在任何地方露面。无限滚动那一行也值得单说——它把分页位置这个本来可见的东西也变没了，用户滚了十屏之后既不知道自己在第几页，也不知道后面还有多少，更没法把这个位置分享给别人。这是范围保管里少数几个“以前做对了、后来主动做没的”例子。

顺带说，这类“存在但不可见”的东西还有一层麻烦：它们会让内链结构悄悄失真——分页与筛选衍生出的地址会吸走大量链接，这一侧的账在内链结构自己会烂掉那篇里算过。

无障碍标准把“你现在在哪”放在了哪一级？

讲到这儿会有个自然的疑问：这么基础的一件事，无障碍那套标准里总该管吧？

管了。但管的方式很值得看一眼——它不仅解释了为什么行业做成这样，还顺带解释了后面那条法律为什么拦不住。

把87条准则的级别数了一遍

先交个底。为了不凭印象说话，保哥把网页内容无障碍指南2.2版的规范原文整份拉下来，把里面每一条成功准则的编号、标题和达标级别都提出来数了一遍。结果是这样：

• A级31条——最低门槛，几乎所有把无障碍写进合同或采购条款的场景都要求它。
• AA级24条——各国法规与采购标准事实上的通行要求，也是本文后面那条法律真正落到的那一档。
• AAA级31条——标准自己在合规说明里写明了：不要求整站内容普遍达到这一级。
• 已废除1条——2.2版把关于标记解析的那条删掉了，因为现代浏览器的容错已经让它失去意义。

合计87条，有效86条。这个总数本身不重要，重要的是三分之一的准则待在一个“没人要求你做到”的档位里。哪些条目被分到那一档，就成了一件很有信息量的事。

可导航这条指南的原话，把三件事写进了同一句

准则不是平铺的，它们挂在若干条指南下面。管导航的那一条编号是2.4，标题就叫“可导航”。它的正式表述只有一句：

Provide ways to help users navigate, find content, and determine where they are.

提供各种方式，帮助用户浏览、找到内容，并确定他们身在何处。

一句话，三件事，用两个逗号并列，分量看上去完全对等：浏览、找到内容、确定自己在哪。写标准的人显然认为第三件和前两件同样是导航的组成部分。

然后往下看它挂着的13条准则，级别是这样分布的：

看出来了吗。三件事里，“浏览”有A级兜底，“找到内容”有A级兜底，唯独“确定自己在哪”只对应一条准则，而那条是AAA。

2.4.8的正文短得让人意外，一句话：

Information about the user's location within a set of web pages is available.

关于用户在一组网页中所处位置的信息是可获取的。

就这么一句，AAA级。也就是说，一个站可以完完整整地达到AA级，全程不告诉任何一个用户他现在在哪儿，而这在标准上是完全合格的。

95% 这个数字到这里就不难理解了。它不是行业失职，是行业老老实实按被要求的那条线在做。

链接文字那一对，把“有没有上下文”分了级

同一张表里还藏着一处更精细的设计，跟移动端首页那个59% 严丝合缝。

关于链接说不说得清自己通向哪儿，标准给了两条：

• 2.4.4链接用途（结合上下文），A级：链接的用途可以从链接文字本身，或者链接文字加上可通过程序确定的上下文来判断。
• 2.4.9链接用途（仅凭链接文字），AAA级：提供一种机制，使得每个链接的用途仅凭链接文字就能被识别。

两条的差别只有一处：允不允许借上下文。允许的那条是A级人人要做，不允许的那条是AAA级基本没人做。这个分级本身没问题——一篇文章里的“阅读更多”，靠前面那段话就能明白，何必强求链接文字自带说明。

问题出在，这个分级隐含了一个前提：上下文是存在的，而且是稳定的。移动端首页那一屏恰恰是上下文最稀薄的地方：

• 一屏就那么大，“上下文”物理上装不下几个字；
• 方块之间是并列关系，不像正文那样有前后承接；
• 那个写着“新品”的方块，它的上下文是上面一个大标题“女装”——可用户滚到这儿的时候，大标题已经滚出屏幕了；
• 对屏幕阅读器用户，“可通过程序确定的上下文”要求的是标记层面的关联，而不是“视觉上挨得近”；一堆并排的方块在标记上常常谁也不属于谁。

结果就是：那条宽松的A级要求，在移动端首页这个具体场景里，事实上退化成了跟AAA级一样严格。你想满足它，除了把范围写进链接文字（也就是把“新品”改成“女装新品”），几乎没有别的干净办法——而这正是评测里那条建议的原话，59% 的站没做到。

一条按“最坏情况”定级的规则，落到某个具体场景时，宽松档和严格档会重合；重合的那一刻，规则表面的分级就失去了意义，而没有人会因此把它重新定级。

分级是按内容类型的最坏情况定的，落到电商类目页就失真了

为什么“位置”这条被放进AAA？标准自己的说法是，AAA级的准则“无法对所有内容普遍适用”。这个理由对某些内容是成立的：一篇独立的博客文章、一份上传的表单、一个单页的活动站，你要它说清“用户在一组网页中的位置”，确实有点强人所难——它压根不在一组网页里。

但电商类目页是什么？

• 层级是固定的，且已经存在于商品目录里；
• 页面是模板渲染的，做一次全站都有；
• 层级信息在服务端本来就在手上，不需要额外计算；
• 页面数量巨大，边际成本趋近于零。

换句话说，这是全互联网上最容易满足2.4.8的一类内容，却和最难满足的那类内容共用一个级别。分级按最坏情况定，落到具体品类必然失真；失真的方向永远是同一个——最容易做到的那批人，跟着最难做到的那批人一起被免除了。

顺便说一句，无障碍这套标准里能被工具自动查的部分其实不少，比如图片替代文本这类硬指标就适合批量扫，图片替代文本的批量体检那篇讲的就是这类活。但凡是涉及“这条信息对不对、够不够”的准则，工具一律无能为力——2.4.8恰好整条都落在工具管不到的那一半里。

还有一条A级准则，被电商站集体浪费掉了

数完那87条之后还有个意外发现。2.4.2“页面有标题”是A级，正文同样只有一句：网页要有描述其主题或用途的标题。

这条几乎所有站都“达标”了——页面确实有标题标签，里面确实有字。但看看那些字是什么：

• “连衣裙 | 秋冬新款低至五折 | 某某官网”；
• “某某官方商城 - 全场包邮”;
• “女装_连衣裙_半身裙_某某”。

第一个把范围埋在了促销语前面，第二个压根没有范围，第三个是十几年前的关键词堆砌，用户读起来像密码。这条A级准则要的是“描述主题”，而这三种写法里没有一种是在描述主题，它们在描述活动、品牌和关键词。

标题这个位置很特殊：它是范围唯一一个天生就在、不用额外开发、还能带到浏览器标签页和分享卡片上的容器。多标签页浏览的时候，用户能不能从标签栏认出“哪个是那个卖毛线的连衣裙页”，全靠它。把它让给促销语，等于把一个免费的范围载体主动放弃了。

更完整的准则原文与达标级别可以直接查无障碍指南2.2的规范正文，每条准则下面都标着级别，翻一遍不用二十分钟；而“位置”那条为什么被定成AAA、标准自己是怎么解释的，写在对应的理解文档里。

把87条按“能不能被工具查”再切一刀

本文开头对11项做过一次“能不能被脚本查”的切分，这个切法对整套准则同样成立，而且切出来的结构一模一样。

• 纯机械可查的：对比度够不够、目标尺寸够不够、图片有没有替代文本、语言属性写没写、标记有没有重复的编号。这类准则的自动化检测工具已经很成熟。
• 只能人判断的：替代文本写得对不对、标题描述得准不准、当前位置信息够不够、错误提示说不说得清怎么改。工具能查出“有没有”，查不出“对不对”。

2.4.8整条落在第二类里，2.4.2的实质部分也落在第二类里——工具能查标题标签存不存在，查不出它描不描述主题。而这一整类准则，恰好也是各家评测里不达标率最高的那一批。

一项要求被遵守的程度，跟它有多重要关系不大，跟它能不能被机器判定关系极大。这不是因为大家只做能被查的事，是因为不能被机器判定的事，压根没有一个稳定的时刻会有人去看它。

欧盟无障碍法案生效之后，这95% 算违法吗？

上一节的结论听着像“没人管”。但从2025年6月28日起，欧盟那边确实有一部强制法律开始管电商网站了，而且它的适用范围写得比很多人以为的宽得多。

那么问题就很直接：一个把当前范围完全不说的电商站，卖到欧盟，违法吗？

答案是不违法。而不违法的理由，比违法本身有意思得多。

它确实把电商服务纳进来了，而且没有过渡期可躲

这部法律是欧盟2019年通过的无障碍法案，正式编号2019/882。几个关键条款值得逐条看：

• 适用范围：第2条列了六类服务，最后一项是“电子商务服务”。定义是通过网站和移动设备远距离提供、以电子方式、应消费者个别请求提供、目的是缔结消费合同的服务——你的独立站正正好落在里面。
• 时间：第31条要求成员国在2022年6月28日前完成转化立法，并自2025年6月28日起适用。这个日子已经过了。
• 范围有多宽：法案的说明部分特意写明，电商服务的无障碍义务应当适用于任何产品或服务的在线销售，包括那些本身已经被这部法律单独覆盖的产品。也就是说，你卖什么不影响这条义务成不成立。
• 微型企业豁免：提供服务的微型企业可豁免。微型企业的定义是雇员少于10人，且年营业额或年资产负债表总额不超过200万欧元。

最后这条对独立站主特别实用，也特别容易被误读。两个提醒：第一，这条豁免的是法律义务，不是用户——你的欧洲客户不会因为你只有8个人就更容易找到商品。第二，它没有缓冲期：法条给的是硬指标，人数或者营收跨过那条线，义务就成立了，不存在“下一个财年再说”。团队从9人招到11人的那个月，合规状态就变了，而这件事通常没有任何人会想起来。

可它给电商专门列的三条，全是支付、身份和安全

接下来是最值得看的部分。法案的附件一第四节列的是“针对特定服务的额外无障碍要求”，其中电子商务服务那一项，全文只有三小条：

(i) 在负责的经营者提供了相关信息的情况下，提供所售产品与服务的无障碍相关信息；
(ii) 确保身份识别、安全与支付功能的无障碍，当这些功能作为服务的一部分（而非作为产品）提供时，应使其可感知、可操作、可理解、健壮；
(iii) 提供可感知、可操作、可理解、健壮的身份识别方法、电子签名与支付服务。

三条，两条讲支付与身份，一条讲商品的无障碍信息披露。

没有一条提到用户能不能找到商品。没有导航，没有类目，没有搜索，没有列表页，一个字都没有。

这不是疏漏，是立法思路的必然：这部法案是一部产品与服务的市场准入法，它盯的是交易能不能完成、身份能不能被验证、钱能不能被支付。“找不到商品”在这个框架里根本不构成一种障碍，因为它不阻止交易，它只是让交易没有发生。

导航只能落进那句“可感知、可操作、可理解、健壮”

那导航归谁管？归第三节的通用服务要求，其中一条是：

使网站（包括相关的在线应用）以及基于移动设备的服务（包括移动应用）以一致且适当的方式无障碍，做法是使它们可感知、可操作、可理解、健壮。

这四个词是无障碍领域的四大原则，法律直接引用了它们。听上去覆盖得很全——导航当然属于“可操作”，知道自己在哪当然属于“可理解”。

但法条只给了四个词，没给任何技术细节。技术细节交给谁？交给协调标准。法案第74条说明写得很清楚：符合按欧盟标准化条例制定的自愿性协调标准的产品与服务，推定为符合本指令的无障碍要求。

而这个领域的协调标准，其网页部分对齐的是无障碍指南的AA级。

闭环到这里就闭上了

把四步连起来看：

一部法律的实际覆盖面，不由法条的措辞决定，由它引用的那份技术标准的达标层级决定。措辞可以写得极宽——“可感知、可操作、可理解、健壮”，四个词几乎无所不包；落地时被裁到AA那一刀，是在另一份文件里砍下去的，谁也没看见。

这条判断可以直接迁到别的合规场景去用。你拿到一份法规，第一反应通常是读法条正文；正确的第二步是去找它引用了哪份技术标准、那份标准要求到第几档。两者之间的落差，就是这部法律真正的边界。类似的落差在商品页那边也出现过，比如列表页上那个每千克单价、以及环保声明要拿得出证据那两条规则，都是法条写得利落、落地口径藏在别处。

还有一处小小的讽刺

翻这部法案的时候注意到一件事：全文唯一一次用到“导航”这个词，出现在第2条第4款的排除条款里——在线地图与地图服务不适用本指令，前提是供导航使用的地图以无障碍的数字方式提供了关键信息。

也就是说，这部管着全欧盟电商网站的法律，唯一一次提到“导航”，讲的是地图导航，不是网站导航。

说这个不是为了嘲笑立法者，恰恰相反——它准确地反映了这件事在所有人心智里的位置。提到导航，先想到的是找路；网站上那个叫“导航”的东西，因为长在屏幕上，被默认当成了视觉设计的一部分，而不是一个会决定用户能不能完成事情的功能。

再往前推一层：那个95%，也是同一个心智的产物。当前位置高亮长得像一个样式，所以它归设计管；而设计交付的是稿，稿上只有默认态。

这套读法可以套到任何一部合规要求上

把前面那个闭环抽象一下，得到一个三步动作，拿到任何一部涉及技术实现的法规都能用：

1. 读法条正文，记下它用了哪些抽象词。“可感知、可操作、可理解、健壮”，“适当的、有效的、可访问的”，“清晰易读的方式”——这类词组本身不构成可执行要求。
2. 找它引用了哪份技术标准。通常藏在“推定合规”那一条里：符合某某标准的，推定为符合本法要求。这一句才是真正的技术口径。
3. 去查那份标准要求到第几档。档位之下的一切，法律都碰不到。

三步走完，你手上就有一份准确的“这部法律管到哪儿为止”。这比读一百篇解读文章都实在，而且解读文章几乎从不做第三步——它们停在第一步，把法条的宽泛措辞直接当成了要求，于是得出“这部法律要求网站全面无障碍”这种既对又完全没法执行的结论。

顺手记下的四处排除项，对做站的人很实用

翻指令2019/882的正文时，第2条第4款那份“不适用清单”值得抄下来，因为它直接决定了改造范围能划到多小：

• 2025年6月28日之前发布的预录制音视频。老的商品视频、品牌片不必回头补字幕和音频描述；那天之后新发的要补。这条对内容量大的站省下的工作量相当可观，值得先把发布时间清点一遍再决定改造范围。
• 那个日期之前发布的办公文档格式文件。历史的尺码表、说明书、报关资料这类挂在站上的文件可以放着不动。
• 在线地图与地图服务，前提是供导航用的地图已经以无障碍的数字方式提供了关键信息。门店地图可以留，但地址、营业时间这些关键信息必须另有一份可读的文本。
• 既非经营者出资、也非其开发、且不受其控制的第三方内容。用户评价、买家秀、嵌入的第三方评测都可能落在这里。

最后一行对电商站的价值最大，也最容易被误用。豁免的前提是三个条件同时成立：不是你出的钱、不是你开发的、不受你控制。你自己搭的评价系统，哪怕内容是用户写的，那个系统本身受你控制，界面部分该合规还得合规；真正被豁免的是那种整块嵌进来的第三方组件。这个边界值得让法务和前端一起确认一次，别拿它当挡箭牌。

还有一条常被忽略：存档性质的内容也在排除之列，条件是它不再更新维护、也不再是完成流程所必需的。老的活动页、下线的类目页如果确实符合这个描述，可以不改——但更好的做法是把它们清掉，反正它们在其他账本上也是负债。

悬停延迟只治了开得太快，关得太快归谁管？

这一节换个角度：把评测里那几条纯交互的建议，跟规范原文对着看一遍。三处对下来都能对出增量——不是规范说得比评测好，是两边各管一半，而这一半通常没人拿出来对。

61% 没有悬停延迟，而延迟只管“开”

先说评测那一侧。悬停触发的下拉菜单如果没有延迟，鼠标从搜索框划过导航条，菜单会一路弹开又关上，这种闪动会让人立刻烦躁。给的建议是加300到500毫秒的延迟，再配一个判断鼠标移动方向的算法，避免误触发兄弟类目。

这个建议是对的，但它管的是菜单什么时候开。规范那一侧管的是另一半：菜单什么时候关。

无障碍指南1.4.13这条准则，标题叫“悬停或聚焦时出现的内容”，AA级，不是AAA。它对所有“鼠标悬停或键盘聚焦触发、移开就消失”的内容提了三条要求，逐条译出来是：

可关闭：提供一种机制，让用户不移动指针悬停或键盘焦点就能关掉这块附加内容，除非它传达的是输入错误、或者它没有遮挡替换其他内容；
可悬停：如果这块附加内容是由指针悬停触发的，那么指针可以移动到这块内容上而它不消失；
可持续：这块附加内容应当一直可见，直到触发它的悬停或焦点被移除、用户主动关闭它、或者它的信息不再有效。

“可悬停”这一条，在巨型下拉菜单上最容易踩

三条里，第二条是电商巨型下拉菜单的重灾区。

想象一下这个场景：一级类目“女装”在导航条上，鼠标悬停后下拉面板从它下方展开，面板很宽，里面分了六栏。用户想点面板右下角的“针织衫”，于是鼠标从“女装”那个词开始，往右下方斜着移动。

斜着走会发生什么？鼠标会先经过导航条上“女装”右边的那一项，比如“男装”。如果实现是“离开触发区就关闭、进入新触发区就切换”，用户会看到面板在半路被换成男装的内容——他要的那一项在移动过程中消失了。

这就是那个“移动方向判断”想解决的问题，业内常见的做法是画一个从鼠标当前位置到面板两个角的三角形，只要鼠标还在这个三角形里移动，就暂缓切换。写成规则大概是这样：

触发区 hover -> 延迟 300-500ms -> 展开面板
鼠标移动时:
  若移动向量落在 [光标, 面板左上角, 面板左下角] 构成的三角内
    -> 判定为"正在前往面板", 抑制兄弟项切换与关闭计时
  否则
    -> 启动关闭计时 (同样 300ms 左右, 不要立即关)
面板内部 hover -> 取消一切关闭计时
Esc 键 -> 立即关闭并把焦点还给触发项

最后那行是第一条“可关闭”要的东西，很多站根本没实现——菜单开了之后，键盘用户没有任何办法把它关掉，只能靠移动焦点。而移动焦点这个动作，恰恰是准则明确排除掉的那种解法。

这类“手势与意图对不上”的毛病在触屏上有另一套表现形式，同一根手指要负责翻页、握持和下单那篇讲的是同一个根子：界面只认最后那个动作，不认这个动作前面那一段过程。

轮播那条建议，正好卡在规范的门槛上

第二处对照更有意思。评测对首页轮播给的建议是：桌面端只有标题的简单幻灯片，5到7秒换一屏；文字多的可以停到10秒；移动端干脆别自动轮播；鼠标悬停时要暂停。

现在看规范。无障碍指南2.2.2 “暂停、停止、隐藏”，A级，正文里管“移动、闪烁、滚动”的那一款写着：任何自动开始、持续超过五秒、且与其他内容并列呈现的移动、闪烁或滚动信息，必须提供一种机制让用户暂停、停止或隐藏它。

把两边并排：

看出那个尴尬没有：评测推荐的“每屏5到7秒”，只要轮播是自动循环的，总时长必然超过5秒，也就必然落在规范的管辖里。而评测通篇没提暂停按钮。一个站完全照着评测的最佳实践做完，配置调得漂漂亮亮，A级那条依然不达标。

这不是评测写错了，是两套体系各自只说自己那一半：可用性研究关心“读不读得完”，无障碍标准关心“控不控制得了”。做产品的人两边都得看，而现实里通常两边都只看了一半。

可点区域那条，规范直接给了硬数字

第三处对照。评测说51% 的站说不清视觉块里的可点区域边界，建议用边框、分隔线、箭头、背景色把边界画出来，移动端最好一个视觉块就是一个可点区域。

规范这边给的是数字。2.5.8 “目标尺寸（最低）”是2.2版新增的AA级准则：指针输入的目标尺寸至少24×24个CSS像素，另有若干例外。往上还有2.5.5 “目标尺寸（增强）”，44×44，AAA级。

这两个数字对做类目导航的人有直接价值，因为移动端子类目那种小方块、那些做成纯图标的筛选清除按钮、还有缩略图角上的收藏心形，是最容易掉到24像素以下的地方。而这一条是能被脚本查的——量元素的可点盒子尺寸，纯属机械劳动。它属于本文开头那张表里“能用脚本查”的那一堆，也确实是这几项里做得相对好的。

把三处合起来，可以列一份很短的清单，都是评测没写而规范写了、且五分钟能查完的：

• 下拉菜单开着的时候，按一下退出键能不能关掉，焦点回不回到触发项；
• 鼠标从触发项斜着移向面板远端，中途会不会被兄弟项抢走；
• 轮播有没有一个能被键盘操作到的暂停控件（不是“悬停暂停”，那对键盘用户不成立）；
• 移动端所有可点小目标是不是都够24像素见方；
• 只用键盘走一遍主导航，能不能进得去、逛得完、退得出。

最后一条通常最快出结果：不少站的移动端菜单开关是一个绑了点击事件的普通容器，键盘根本聚焦不到——整个导航对键盘用户不存在。这一条一旦成立，前面所有关于范围的讨论对这批用户都不用谈了，因为他们连树都进不去。缩略图那一侧也有类似的“存在但到不了”问题，被截断的商品图连自己存在都没说那篇是从另一个角度记的同一类账。

只用键盘走一遍主导航的完整脚本

前面提到“只用键盘走一遍”最快出结果。把它写成一份可以照着做的脚本，八步，不需要任何工具，也不需要懂无障碍：

1. 刷新页面，手离开鼠标，按Tab键。第一次按下去，屏幕上有没有出现一个看得见的焦点框？没有，2.4.7就不达标，后面几步也不用做了。
2. 继续按Tab，数几下能走到主导航的第一项。中间如果要按二三十下才穿过页头，说明缺一个跳过区块的入口。
3. 焦点停在一级类目上，按回车或者下方向键，子级面板展不展开？很多站的下拉只绑了鼠标事件，键盘到这儿就是死路。
4. 面板展开后，继续Tab，焦点进不进得去面板内部？有些实现会把焦点直接跳到下一个一级类目，等于面板里的所有链接键盘都够不着。
5. 在面板里按退出键，面板关不关？关掉之后焦点回没回到刚才那个一级类目上？回不去的话，用户会被扔回页面开头。
6. 切到移动端宽度，用Tab走到汉堡菜单按钮上，按回车能不能打开？这一步的失败率高得惊人——那个按钮很多时候是个绑了点击事件的普通容器，既聚焦不到，屏幕阅读器也不认识它是个按钮。
7. 抽屉打开后，焦点有没有被移进抽屉里？在抽屉里一直按Tab，会不会跑到抽屉后面被遮住的页面内容上去（这是最常见的实现漏洞）？
8. 回到某个类目页，用键盘走一遍主导航，能不能感知到当前所在的那一项？纯颜色差异对键盘用户没问题，但对屏幕阅读器用户，就要看那个当前项属性有没有被读出来。

八步走完通常十分钟。经验上，第三步、第六步、第七步是三个最高频的断点，而且它们的共同点是：只要断在其中任何一处，这批用户就完全用不了主导航——不是体验差一点，是整棵树对他们不存在。

触屏上没有“悬停”这件事，比想象中影响更大

前面讲的悬停延迟、意图三角、悬停暂停，在触屏上全部不成立，因为触屏没有“指针停在某处但还没按下”这个中间状态。这带来一串连锁反应：

• 信息线索少了一层。桌面端悬停一个类目能预览子级，触屏必须点进去才知道里面有什么——这就是为什么子类目缩略图在移动端比桌面端重要得多。
• “悬停暂停”对轮播失效。所以移动端的正确做法不是调慢，是干脆别自动轮播。
• 误触成本高得多。桌面端鼠标划过一个链接什么也不会发生，触屏上手指碰到就是点击，这让“可点区域边界不清”这条在移动端的杀伤力翻倍。
• 没有光标形状这个提示。桌面端鼠标变成手形就知道能点，触屏上完全没有这个反馈，所以“看起来能点但其实不能”在移动端是纯粹的死路。

四条合起来解释了那个67% 对58% 的差距：移动端不是把桌面端的问题缩小了显示，是少了一整套用来自我纠错的中间状态。

颜色改一改就算高亮了吗？

回到那个95%。评测给的解法是这样一句：提供当前位置的信息有一个成本很低的办法——把当前一级类目在主导航里的样式做得跟其他项不同就行，可以简单到只是换个字体颜色，关键是要跟其他项区分得足够明显。举的例子是某英国零售商把当前所在的一级类目染成亮绿色。

这个建议实用，方向也对。但它有个问题——它跟一条A级准则直接顶上了。

“只靠颜色”是A级不许的

无障碍指南1.4.1 “颜色的使用”，A级，原文一句话：

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

颜色不得作为传达信息、指示动作、提示响应或区分视觉元素的唯一视觉手段。

“区分视觉元素”这五个字就是把当前项从其他项里区分出来，一字不差。所以把当前类目染成绿色、其余保持黑色，如果只做了这一件事，它同时是一条被推荐的最佳实践、和一条A级不达标项。

受影响的不只是完全看不见颜色的人。绿色和黑色这一对对绝大多数色觉障碍类型其实还算安全，真正常翻车的是那种“当前项用主题色，其余项用深灰”的做法——主题色如果本身偏暖偏深，两者的明度差可能小到在灰度下几乎看不出来。这类对比够不够，是可以直接算的，颜色换算与对比度实操那篇里有具体算法和阈值。

补救成本几乎为零，只要在颜色之外再加一个非颜色的差异：

• 加粗（字重差异，灰度下依然成立）；
• 底部一条下划线或者色条（形状差异）；
• 前面一个小圆点或者箭头（增加一个元素）；
• 背景块（面积差异，最明显）。

随便挑一个跟颜色叠着用就够。这是本文里性价比最高的一条改动：一行样式，同时补上一条A级准则和一条转化相关的体验缺口。

那个专门表达“当前”的属性，能说清什么

视觉这一侧解决了，还有辅助技术那一侧。无障碍标记里确实有一个专门表达“当前”的属性，叫 aria-current。它有七个取值：

对电商导航来说，aria-current="page" 是标准答案，加在当前所在的那个导航项上。规范还提醒了一句：一组元素里只应该标一个当前项——多级导航里“女装”和“连衣裙”都标成当前会让辅助技术无所适从，正确做法是只标最深那一级。

规范原文把它的前提写死了：它是记录者，不是创造者

这个属性的定义里有一句话，读到的时候值得停一下：

The aria-current attribute is used when an element within a set of related elements is visually styled to indicate it is the current item in the set.

当一组相关元素中的某个元素已经在视觉上被设置了样式以表明它是当前项时，使用 aria-current 属性。

它的适用条件，是“视觉上已经标出来了”。

换句话说，这个属性的职责是把一个已经存在的视觉事实翻译给辅助技术听，它不负责创造那个事实。规范假定视觉高亮先存在，标记跟在后面。

这对那95% 意味着什么很清楚：那些站连视觉高亮都没有，属性这一侧根本还轮不到。你不能靠加一个属性来补上一个不存在的态——加了，屏幕阅读器用户能听到“当前页”，眼睛看得见的用户依然一无所知，两边的信息量还不一样。

顺带一提，这条分工在智能体时代变得更要紧了：现在读你页面的除了人和爬虫，还多了一类东西，它们读的正是这套无障碍标记而不是渲染出来的画面，这件事在智能体读的是无障碍树不是页面截图那篇里讲过。结论没变，只是听众多了一类：视觉和标记要说同一句话，缺哪一边都是残的。

那五个具名取值，全都是一条线上的位置

把七个取值再看一遍，有件事挺明显：五个具名的取值——页码、步骤、流程节点、日期、时刻——描述的全是一维序列上的位置。第几页、第几步、第几个节点、哪一天、哪一刻。它们都能排成一条线，说清“当前”只需要一个下标。

类目树不是一条线，是一棵树。筛过之后的范围连树都不是——它是树上某个节点，再叠上若干条件的交集。要说清这个东西，一个下标远远不够。

所以别对这个属性期待过高。它能干净地表达的是“你在导航的这一项上”，表达不了“你在女装的连衣裙里、只看黑色的、只看一百元以下的、共128件”。这一句只能靠正文里的文字说出来，没有任何标记能替它。

那就把这句话写出来，三种写法

与其纠结属性，不如直接落三个位置。这三处互不替代，做全了才叫范围保管到位：

• 页面主标题：写类目全名，别让促销图把真正的标题顶掉。解决的是从站外直接落地的人第一眼能不能定位——这批人通常是流量占比最大的一批。
• 主导航里的当前项（桌面端常驻、移动端在抽屉内）：颜色加一个非颜色差异，再补上 aria-current="page"。解决的是让人慢慢建立起对整棵树的认识，知道自己在这棵树的哪一根枝上。
• 列表上方那条吸顶的结果条：类目路径加全部已选条件加实时件数，每个条件后面带一个能去掉它的入口。解决的是筛选、排序、翻页之后的当下范围。

第三处是最容易被漏掉、也是回报最大的一处，因为它是唯一一个能跟着变化走的。前两处在用户勾第一个筛选条件之后就不再准确了，只有它一直准确。

做这一条有个细节要注意：件数必须是真实的当前件数，不能是缓存的类目总数。写了一个不对的数字比不写更糟——不写只是没说，写错是说了假话，而用户会拿这个数字去判断这家店值不值得逛。

那条结果条，八个细节做错一个就废一半

前面说列表上方那条结果条回报最大。它看着简单，实际有八个坑，随便踩一个效果就少一半：

• 要吸顶。不吸顶的话它只在第一屏有效，而用户翻到第三屏之后才是最需要它的时候。
• 件数必须实时。拿类目总数糊弄，用户勾了三个条件件数还是1280，这行字立刻失去全部可信度。
• 每个条件后面带一个去掉它的入口。只显示不给操作，等于让用户滚回筛选栏去找那个勾——而找不找得到是另一个问题。
• 用词要跟用户点的那个按钮一模一样。他点的写着“深蓝”，结果条上写“藏青”，他会以为自己点错了。
• 去掉一个条件之后，要能告诉他剩多少件。做得好的会直接把数字写在入口上：“去掉价格限制 → 17件”。这一条成本略高但价值很大，它把“要不要放弃这个条件”从赌博变成了选择。
• 条数为零时不能消失。恰恰这时最需要它——见前面讲空结果那一段。
• 移动端不能塞进折叠区。为了省空间把它收进“筛选（3）”这样一个小标签，等于回到了什么都不说的状态；宁可让它换行占两行。
• 它必须是文字，不能是一串图标。纯图标的标签组既读不出来，也没法被搜索引擎和辅助技术理解。

八条里第五条最能拉开差距。多数站的筛选交互是“盲选”——用户不知道勾上这个条件之后还剩几件，只能勾了看、不合适再取消。把预估件数标出来，本质上是把范围的下一步变化提前告诉他，正好对应三句判据里的第三句。

件数这个数字，工程上比看起来麻烦

实现的时候会遇到一个绕不开的问题：实时件数要额外查一次总数，而带多条件的计数在大目录上不便宜。常见的三种处理：

• 每次筛选都精确计数。查询成本最高，结果最可信。目录规模中等、检索层撑得住的站可以直接这么做。
• 超过某个量级就只显示“1000+”。基本无额外成本，而且诚实。大目录首选，实测下来用户对这个写法完全不反感，因为它传达的信息已经够用了。
• 用近似值并标注“约”。成本低，但一旦用户翻到底发现对不上，这行字的信任就没了。除非误差能压在个位数百分比以内，否则不建议。

第二种是性价比最高的。用户需要的不是精确数字，是一个能支撑判断的量级——“共7件”和“1000+”传递的信息完全不同，而“1247件”和“1000+”对他的决策没有任何区别。

标记那一侧也别忘了：WAI-ARIA规范里那个表达“当前项”的状态只管导航项，管不了结果条。结果条的内容变化要让屏幕阅读器知道，靠的是把它标成一个实时更新区域，让内容变了之后被自动播报出来——否则视觉用户看到数字跳了，听声音的用户什么都不知道，又是一次信息不对等。

不埋点的话，怎么看出用户在替系统记范围？

到这一步，大概率会遇到同一个问题：讲得都对，可怎么证明我们站上真有这个毛病、值不值得排期？

常规答案是埋点。但埋点这条路在这件事上不好走：你要埋的是“用户失去了方向感”，而这个状态不产生任何事件——他没点错，没报错，没多点，只是理解错了。没有一个动作对应它，也就没有一个事件能埋。

好在有五个指标，全部能从已有数据里切出来，不需要新埋任何东西。它们量的不是“迷路”本身，是迷路之后必然出现的那些代偿动作。

五个指标

五个指标里，第四个最省事，因为它完全不看用户行为：一份站点地图或者一次全站抓取，加一份服务器日志，两条统计就出来了。第二个最值钱，理由见下面。

四条口径修正

直接照上面的定义去算，几乎肯定会算出假信号。四个必须先处理的口径问题：

• 兄弟类目要按最深一级判定。“男装 > 鞋”和“女装 > 鞋”不是兄弟，它们是两棵子树上的同名节点。按名字判定会把正常的对比浏览算成横跳，数字直接翻倍。
• 往上退的判定要排掉浏览器后退。用后退键回上一层跟点面包屑回上一层，行为含义完全不同：前者是“我看完了要换一个”，后者常常是“我根本不该来这儿”。后退在多数分析工具里要么不产生新的页面浏览、要么产生一条重复记录，得按来源页和时间间隔折叠掉。
• 移动端菜单要排掉误触。打开后1.5秒内关闭且没有任何点击的，算误触不算一次使用。汉堡按钮的位置和拇指自然停放的位置高度重合，误触比例比想象中大。
• 第一次点击是搜索框的要单独归一类。他到了深层页第一件事是去搜索，这不是“在用导航找坐标”，这是“放弃导航改用搜索”。两种都是信号，但含义相反，混在一起会把结论搅浑。搜索框那一侧本身也有一堆讲究，见独立站搜索框的四层拆解。

中间层类目页，是唯一一个考核指标被安错了的页面类型

五个指标里，第二个值得单独说，因为它牵出一个几乎所有电商站都有的结构性错误。

中间层类目页是什么？就是“女装”这一层——它下面还有连衣裙、上衣、裤装、外套，它自己通常不直接列商品，或者只列一小部分。评测里那个76%，说的就是这类页面把子类目埋在了促销位下面。

问题在于，这类页面在后台报表里是跟其他页面用同一套指标考核的：转化率、加购率、页面价值、跳出率。而它根本不该被这么考核。

它的职责是把范围收窄一次，然后把人交出去。它自己不该产生转化，它产生的转化越多，往往说明子类目做得越差（用户放弃了继续收窄，直接在这一层的推荐位里凑合挑）。

但报表不管这些。运营看到“女装”这一页转化率低，第一反应是往上面加东西：加个爆款推荐位、加个满减横幅、加个新品轮播。每加一样，子类目就被往下推一屏。76% 就是这么来的——它不是设计失误，是一个被安错的考核指标，通过一次次合理的局部优化，稳定地把页面推向错误的方向。

换成“往下走占比”这一个数，动作方向立刻反过来：为了让这个数上去，你会想把子类目往上提、把缩略图做清楚、把每个子类目下有多少件商品标出来。同一个页面，同一批人，换一个数字就换一套动作。

三种横向基准，用来判断数字算不算差

拿到数字之后还有一步：多少算差？这几个指标没有行业公开基准，只能拿自己跟自己比。三种切法：

• 按层级深度切。越深的类目页，横跳率理应越低（都到第四层了应该很确定）。如果深层反而更高，说明深层的类目名分不清——这是最常见的一种，通常是类目树在末端做过一次拆分而名字没跟着改。
• 按设备切。移动端各项数字比桌面差是正常的，差1.5到2倍属于常态。差到3倍以上，八成不是“移动端本来就难”，是某个东西在小屏上塌了——最常见的是当前范围那行字被挤到折叠区里去了。
• 按流量来源切。从站外深层落地的会话（搜索、广告、社交）和从首页逐层点进来的会话分开算。前者理应更依赖页面自己说清范围。如果两者数字差不多，那不是好消息，说明逐层点进来的人也没建立起方位感——树本身就没被理解。

什么时候这些数字不该看

三种情况，先别急着投入：

• 品类极窄的站。总共二三十个商品、一层类目，用户三次滚动能看完全部库存，范围这件事不构成问题。判据很简单：数一下有多少会话访问过两个及以上类目页，比例低就说明多数人根本没在用类目。
• 搜索主导的站。如果进入商品页的上一步是站内搜索的占比远高于类目浏览，那导航不是主矛盾，该先修搜索。这类站的整体体验账要连着搜索一起算，参见把搜索、体验和转化拧成一条链。
• 刚做完大改版的头一个月。老用户的肌肉记忆会让所有导航相关指标短期变差，这段数据没有参考价值。

还有一个必须提前说清的口径迁移：把范围说清楚之后，类目页的跳出率大概率会往上走一点。原因不难理解——以前用户要翻三屏才发现这儿没有他要的，现在顶部那行字加上件数，他五秒就知道了。这批人本来也不会转化，只是他们的离开时间提前了，在报表上从“逛了三页才走”变成“看一眼就走”，看起来像页面变差了。这个变化要在动手之前讲，不能等报表出来再解释，否则说什么都像是在找补。

这五个数从哪儿拿，一个新埋点都不用加

“不用埋点”这话得能兑现，否则就是空头支票。五个指标各自的数据源列清楚：

• 兄弟类目横跳率——分析工具里的页面浏览序列，按会话拉出来，用地址前缀判定父子关系。半天，时间主要花在写类目路径的解析规则上，而不是取数。
• 中间层页去向拆分——同一份序列数据，看每个中间层页面的下一跳属于哪一类。两小时，前提是中间层页面有稳定的地址特征能被认出来。
• 深层落地的首次交互——分析工具的落地页维度加上事件序列；实在没有事件数据，用“落地页到第二个页面”的跳转目标做近似也够用。两小时。
• 网址变体的产出与消费比——产出端用一次全站抓取或者现成的站点地图，消费端用服务器访问日志。一小时，而且完全不依赖前端埋点，不需要任何人配合。
• 移动端菜单开合次数——这一项确实可能得加一个事件。如果你们的导航展开会改变地址（有些实现会往地址里加片段），也能从序列里还原出来。

第四个最值得先做，因为它一小时出结果、完全绕开前端、而且不需要任何人配合。服务器日志本来就在，全站抓取跑一遍也就一杯咖啡的时间。这个比值一旦算出来是几十比一，讨论的气氛会立刻不一样——它是这五个数里唯一一个能让技术和运营同时闭嘴看数字的。

五个指标的排期顺序：两维相乘

五个不可能同时做，排序用两个维度相乘：

• 拿到成本：从现有数据里能不能直接切出来，还是要改代码。
• 结论的行动性：这个数难看之后，你知不知道下一步该动哪里。

按这两维排，顺序是：网址变体比（成本最低、指向明确）→ 中间层页去向（成本低、结论直接对应“把子类目提上去”）→ 深层落地首次交互（成本中、指向“页面自己没说清”）→ 兄弟类目横跳（成本中、指向类目命名，而改命名牵扯较广）→ 移动端菜单开合（可能要埋点，放最后）。

这个排序有个反直觉之处：信息量最大的那个未必排在前面。兄弟类目横跳率其实是五个里最贴近“用户迷路”本质的一个，但它的结论指向类目命名，而改类目命名要动商品运营、动地址、动收录，是一个季度级的工程。先做那些“数字难看 → 下周就能动手”的，比先做那些“数字难看 → 开三个月的会”的划算得多。

选指标的时候，不要只问它能说明什么，还要问它说明之后你能立刻做什么。一个没有对应动作的指标，看完只会变成焦虑。

把它焊进组件库，比写进设计规范省力

前面九节讲的都是“这件事为什么会丢”。这一节讲怎么让它丢不了。

先排除两个看起来最自然、实际最没用的位置。

不要挂在设计评审上。设计评审天然对着一张稿看，而当前态是一个“态”——稿上画的永远是默认态。你在设计评审上提“当前范围有没有说清楚”，对方会翻到导航那一页说“你看这不有嘛”，指的是那棵树。这个会开不下去，不是因为对方不讲理，是因为讨论的载体不支持讨论这个问题。

也不要写进设计规范文档。规范文档的执行力取决于有没有人查，而这一条恰恰是最难查的那种——需要人打开页面、补一句话、判断对不对。写进去很容易，一年后没人记得。

卡点只有一个：导航组件那个参数没有默认值

真正有效的位置在组件库。具体到一行：导航组件接收当前范围的那个参数，设成必填，不给默认值。

就这一条。它的全部威力来自一个很朴素的机制：

把一个可选参数改成必填参数，是最便宜的一种组织手段——它不需要任何人认同这件事重要，只需要编译不过。

展开说说这条为什么比讲道理管用。

你要求调用方必须显式传入当前范围，那么每一个用到导航的页面模板，都必须回答“我是什么范围”。绝大多数模板能立刻答出来（类目页当然知道自己是哪个类目）。答不出来的那几个，就是这次改造真正的收获——它们是那些自己也不知道自己代表什么范围的页面：营销落地页、活动聚合页、从搜索结果直出的伪类目页。这些页面平时藏得很好，只有在被逼着填一个必填参数的时候才会露出来。

落地的时候还有几个细节：

• 参数值不能是可选类型。允许传空等于没改，人人传空，一切照旧。
• 确实没有范围的页面，要有一个显式的值，比如“无范围”。关键在于它是被人主动选的，而不是没写。这两者在类型系统里看不出区别，在追责时区别很大。
• 参数的类型要能表达完整范围，不能只是一个类目编号。至少要装得下：类目路径、已选筛选条件、结果件数。装不下，那行字就写不出来。
• 顺手把无障碍属性的输出焊在组件内部，别让调用方各写各的——组件既然拿到了当前范围，标记就该由它统一生成。

会遇到的三种反对，以及答法

再配一条跨项目通用的纪律：新加的检查项，先造一个必然失败的例子，确认它真的会红。把参数改成必填之后，随手起一个不传参数的页面，跑一遍构建，看它是不是真的挂了。不做这一步，很容易出现“规则加了但被某个默认配置吞掉了”，然后半年后才发现一直是绿的。

四条边界，主动说在前面

• 不解决类目树分得不对。把范围说清楚，只会让“这棵树分得不合理”这件事更早暴露，不会让它消失。
• 不保证转化率上涨。这一条前面提过一次，值得再说：它会救回一部分本来会走的人，同时也会让一部分本来会盲目往下逛的人提前离开。两股力量方向相反，净值可能落在噪声里。
• 对单层扁平的小站价值有限。判据是那条会话统计，不是拍脑袋。
• 它不是一次性工程。范围这件事会随着新增筛选维度、新增地区、新增会员价体系不断长出新的破口。今天做完，明年上线一个“仅显示有货”的默认过滤，那行字如果没跟着更新，缺口当场就回来了。

一次没看出来的失手：那条预警被归进了“设计参考”

说个保哥自己没看出来的例子，因为它的预警形态跟以往每一次都不一样，而且这一次预警不但存在，还被写进了正式文件里，还被所有人认真读过。

这个站原本什么样

一个做手工艺材料的跨境独立站——毛线、布料，加上缝纫和编织的辅料，卖到北美和西欧，客单价三十到一百五十美元。这个品类有个天然特征：类目树又深又宽。光毛线一条线，就要按纤维成分、粗细规格、每团克重、色系、品牌分，四五层是常态，末端类目上千个。

原状是流量稳定、加购率正常、复购不错，报表上没什么明显毛病。团队的注意力那阵子在改版上——半年里换了两版主导航，从多级下拉换成分栏式巨型菜单，移动端汉堡菜单重做了一次。改完之后大家都觉得清爽多了。

预警长什么样

预警来自一份竞品调研。运营做季度竞品分析的时候，截了几个欧美同行的类目页放进报告，其中一张图旁边写了一句：“他们这个当前分类的高亮做得挺好看的，整体视觉更统一。”

这句话被归进了报告的“设计参考”那一栏。

那份报告开会读过，大家点头，觉得对方视觉确实成熟。然后这一条就再没有下文了。

为什么这种最难被识别出来

难点不在于没人看见，而在于它被归进了一个天然不产生行动项的类别。

任何一家公司里，“审美类观察”都是约束力最弱的一类输入。它没有量化，没有受害者，没有截止日期。“人家做得好看”这句话在会议室里的标准结局就是被记录、被认同、然后什么也不发生。

更麻烦的是，这句话把问题的性质说错了。它把一个功能缺失描述成了一个视觉差距。一旦这个描述被接受，后面所有讨论就都跑到视觉那条路上去了：要不要统一一下配色？导航的字号是不是该调？要不要请个设计外援？

一条被归错类别的观察，它的伤害不在于当时没被采纳，而在于它替真正的原因占了位置。之后每一次有人重新提出这个问题，都会被一句“这个我们讨论过，是视觉问题”挡回去。

怎么翻过来的

靠的是那个笨动作。做一次常规体检时，从站外直接粘一个第四层类目页的地址进无痕窗口，不滚动，试着补那句“我现在看到的是____里的商品”。

补不出来。整个首屏上，唯一能提供线索的是一张促销横幅，写着“秋冬毛线上新”。而那个页面实际是“羊毛混纺 > 中粗 > 50克装”。

缩到手机宽度再来一次，更糟——桌面端导航条上那点微弱的当前项色差，在移动端连导航条都没有。

再加一个筛选条件，那行促销横幅纹丝不动。

三张截图并排放进下一次会议，没有解说词。那份竞品报告里说的“视觉更统一”，到这一刻才被翻译成它真正的意思：对方那个页面知道自己是谁，我们这个不知道。

真正做的三件事

1. 列表上方加了一条会跟着变的结果条：类目全路径加全部已选条件加实时件数，每个条件后面带一个去掉它的入口，吸顶。
2. 中间层类目页的考核换成了“往下走占比”，顺手把压在子类目上面的两个促销位挪到了子类目下面。
3. 导航组件的当前范围参数改成必填。这一步逼出了30多个“说不清自己是什么范围”的页面，其中一批是历史活动页，直接下线了；另一批是搜索结果直出的伪类目页，补了显式范围。

结果，以及一个不好看的变化

结果分两半说。

好的那一半：兄弟类目横跳率明显下降；中间层类目页往下走的占比涨了一截；客服那边“你们有没有某某规格的毛线”这类问题少了——这类问题以前一直被当成售前咨询，现在回头看，每一条都是站上没说清范围、用户只能来问人。

不好看的那一半：类目页跳出率涨了。结果条把件数写出来之后，一部分用户看到“共4件”就直接走了。这些订单本来也成不了，但报表上它们从“逛了几页才走”变成“看一眼就走”，中间层类目页的停留时长跟着掉。这个口径迁移是提前讲过的，所以没有变成事故；如果没提前讲，光凭事后解释很难让人信服。

还有一件事值得记一笔：那份竞品报告没有人回去改。“对方视觉更统一”这句话至今还留在那份文档里，而真正的差距是另一回事。这类修复天然吃亏——收益分散在客服、转化、抓取预算好几本账上，而当初那个错误的结论一直挂在那儿，等着下一次被引用。解法很土：动手之前，把当时那句被归错类的原话抄下来，做完之后在它旁边补一行“这条实际上指的是什么”。不为了追究谁，是为了让下一个人别再从视觉那条路上走一遍。

头90天怎么排，才不至于开一堆会

这件事最容易死在启动阶段——因为它跨了太多角色，谁都能插话，谁都不必负责。给一个按周排的版本，重点是把需要共识的部分尽量往后推。

这个顺序的用意很明确：前四周全是不需要说服任何人的事，做完手里就有了图、有了数、有了一个已经上线的对照。等到第五周要动运营的考核口径时，你不是拿一个观点去谈，是拿三张截图和两个数字去谈。

顺序反过来的话——先去开会讨论“要不要重视当前范围”——大概率会卡在第一次会议上，因为对方没有任何东西可以反驳，也没有任何东西可以认同，会议只能以“我们再研究研究”结束。

最后收一句

这一整篇讲的其实是一个很小的东西：用户脑子里那句“我现在看的是什么”，屏幕上有没有一份对应的副本。

它小到没有一个岗位的职责描述里写着它，小到设计稿上画不出来，小到自动化测试碰不到，小到连一部已经生效的强制法律都因为技术标准的档位划分而绕过了它。也正因为小，它在过去一年里被静态化和组件化顺手挤掉，评测数字从91% 变成95%，而整个行业没有一个人在那一刻记账。

保哥这些年看下来，凡是这种“每个零件都有主人、拼起来那句话没有”的问题，都有一个共同的解法方向：别去说服人，去改默认值。把一个可选参数改成必填，把一个考核指标从转化率换成往下走占比，把一份态清单加进交付物——这三件事都不需要任何人先认同它重要，它们只是让“不做”这个选项在流程上不再成立。

而至于怎么知道自己站上有没有这个毛病，方法在前面已经给完了，五分钟，一个无痕窗口，一句话：

我现在看到的是____里的商品。

补不出来，就是有。

常见问题解答

电商网站的类目导航怎么设计才不让用户迷路？

先别急着改菜单树的形状。多数站真正缺的不是层级设计，是没有任何一处告诉用户“你现在看的是哪一批商品”。落地做三件事：页面主标题写类目全名、不要被促销图顶掉；主导航里当前项用颜色加一个非颜色差异标出来；列表上方加一条会跟着变的结果条，写清类目路径、全部已选筛选条件和实时件数，每个条件带一个去掉它的入口。三处里第三处回报最大，因为只有它能跟着用户的操作一起变。做完再回头看层级要不要调，多半会发现原来的层级没那么糟。

面包屑导航和当前范围提示是一回事吗？

不是。面包屑写的是当前页面在类目树上的祖先链，来源是类目结构；范围是用户此刻看到的这批商品由什么决定的，除了类目路径，还包括他勾选的筛选条件、排序方式、当前页码、所在地区决定的可售集合，以及那个默认隐藏无货商品的开关。用户在左侧勾了五个条件，面包屑一个字都不会变。所以“我们有面包屑”是一个正确的回答，只是它回答的是另一个问题。两者都要有，且分工不同：面包屑负责往上退，结果条负责说清当下。

主导航里高亮当前类目，只改颜色可以吗？

不够。无障碍指南1.4.1是A级准则，明确写着颜色不得作为区分视觉元素的唯一手段，而把当前项染成另一种颜色恰好就是拿颜色区分元素。补救成本几乎为零：在颜色之外再叠一个非颜色差异就行，加粗、下划线、底部色条、前置小圆点、背景块，随便挑一个。另外别忘了标记那一侧，在当前项上加aria-current属性，取值用page，且一组元素里只标最深那一级。视觉和标记要说同一句话，缺哪一边都是残的。

一个类目下最多放多少个子类目合适？

大规模测试里的常见分界是10个左右：超过这个数，多数人开始出现“选项太多”的反应，移动端因为要滚动，感受更明显。所以经验做法是接近10个就往下再分一层，同时保证最深一级类目里至少还有10件商品，否则分下去就是空架子。但这个数字别当硬指标用，它真正说明的是另一件事：分块的目的是让人一眼扫完，如果你的子类目名字长短悬殊、命名口径不统一，那么八个也会显得乱；反过来命名整齐、带清楚的缩略图，十二个也扫得动。

分面筛选产生的大量网址，对用户体验有影响吗？

有，而且方向和抓取问题正好相反。抓取那一侧的病症是过剩：一个范围对应成千上万个地址，吃掉抓取预算、造出近似页面。用户这一侧的病症是缺失：同样这个范围，屏幕上一个字都没写。同一个变量，机器那侧存了无数份，人那侧一份都没有。要注意的是，把带参数的地址统统指向不带筛选的规范网址，只解决了机器那一半；用户从搜索结果落到不带筛选的页面上，看到的东西和他搜的具体需求对不上，这个问题规范网址管不了。

欧盟无障碍法案要求电商网站的导航做到什么程度？

比多数人以为的松。指令2019/882确实把电子商务服务纳入了适用范围，自2025年6月28日起适用，微型企业（雇员少于10人且年营业额或资产负债表总额不超过200万欧元）可豁免。但它给电商专门列的三条额外要求全是关于身份识别、安全与支付，没有一条提到用户能不能找到商品。导航只能落进那句“可感知、可操作、可理解、健壮”的通用条款，而这句话的技术口径由协调标准填，对齐的是AA级；说清用户当前位置的那条准则是AAA级，不在要求内。

不做用户测试，怎么判断自己站的导航有没有问题？

五分钟的动作就够。开一个全新的无痕窗口，直接把一个第三层类目页的地址粘进去回车，不滚动，就看首屏，试着把“我现在看到的是____里的商品”这句补完。补不出来就是有问题。然后把窗口拖到手机宽度再来一次，多数站会在这一步掉一大截。再加一个筛选条件，看那句话变没变。最后点进一个商品再用面包屑退回来，看筛选条件还在不在。三张截图并排，不需要解说。你没法跟人争论用户会不会迷路，但没法否认这一屏上没写类目名字。

权威参考资料