10 月 27 日晚上十点四十，我在客厅把 Switch 2 从底座上拔下来，第三次清掉它的首页缓存

我把那台机器放在茶几上，屏幕朝下，因为不想再看它跳出来的那一行转圈动画。10 月 27 日晚上十点四十，我在客厅把 Switch 2 从底座上拔下来，第三次清掉它的首页缓存，然后打开秒表，记下第三次加载的用时：1.8 秒，比前一天同一时刻慢了 0.6 秒。这个数字本身不重要，重要的是它为什么每次都出现在「第三次」。

九次测量，六十三天里我记了整整一页。

接下来的几天我做的事情很笨：先排除网络，用同一个路由器在手机上跑同样的入口，中位数是 0.7 秒，说明链路不是瓶颈；再排除账号，用一个刚注册的临时账号登录，加载时间反而比主账号稳定；最后只剩下缓存分区这一层，而这一层恰恰是任天堂从来不对外解释的部分。我翻完了手边能找到的资料，包括那本 2011 年的《The Web Application Hacker's Handbook》，第 12 章关于客户端缓存的讨论里有一句话让我停了很久——「缓存的失效策略往往暴露服务端对用户行为的假设」。换句话说，入口慢不是因为机器笨，是因为它在猜我接下来要做什么，而且猜得不准。

一个我必须承认的立场

说实话，我认为「任天堂switch2入口浏览器」这个说法，被讨论得太多，被定义得太少。绝大多数把它挂在嘴边的人，指的其实是首页推荐位；少数人指的是那个藏在设置菜单深处、只在特定操作下才会被唤起的网页视图；还有人在论坛里把它和商店页面混为一谈。这四种东西在技术上是完全不同的对象，共享同一个名字，然后大家一起抱怨它慢——这种抱怨是没有意义的，因为你连抱怨的对象都没确定。这是我今年写过最不讨喜的一句话，但我不打算收回。

为了把这件事说清楚，我把它拆成了三个可观测的对象：其一，开机后自动呈现的推荐面板，它读取的是缓存的首页快照；其二，掌机模式下从某个图标进入的内嵌页面，它走的是一次完整的会话初始化；其三，系统设置里的网络相关页面，它是唯一一个明确告诉你「正在连接」的地方。三者的加载曲线完全不同，而我在路由器日志里抓到的那 41 个请求域名，只有 9 个是三者共用的。剩下 32 个各管各的，其中 11 个带着版本号参数，这意味着每次版本更新，缓存都要重建一次——这大概就是「第三次变慢」的一种解释，虽然我还没有证据把它坐实。

顺便说，老陈那句「你就当它是个黑盒，别拆」，我现在有点同意，也有点不同意。

还没答案的四个问题

• 版本号参数是谁决定的？是内容分发侧的惯例，还是入口页面自己加的防缓存手段？如果是后者，那它的目的是保护内容，还是保护统计？
• 为什么第三次打开才会变慢？我怀疑与某个后台预取任务有关，但没抓到确切的请求序列。
• 掌机模式和底座模式共用会话，却不同步缓存分区，这是设计取舍还是历史遗留？
• 如果一个入口浏览器的首要职责是「让你尽快离开它」，那么它的性能指标应该怎么定义？

我把这四个问题抄在了笔记本第 38 页，旁边贴着田中那张 2013 年的 Wii U 说明卡照片。那张卡上写着「开机即游玩」，一共五个字，没有提到任何浏览器。十三年过去，入口这件事被拆成了几十层，其中大部分我们看不见，也很少有人愿意承认自己看不见。我不打算在这一篇里给出结论，因为结论还没有出现。我打算下周继续测，把 63 条记录补到 126 条，然后看看那条曲线会不会自己说话。