Chromium 129 首屏 2.3 秒的背后，是它先请求了缩略图索引
我在开发者工具里看到，Chrome 先取一个小体积索引文件，再按视口分批拉图。这个顺序是它能快速出图的关键。
49图库恢复正常使用免费打开49使用方法下载 · 实测记录
10 月 25 日晚上九点四十分，我把 49 图库在 Chrome 129 和 Edge 130 上各打开了一次
两次结果不一样：Chrome 里图集缩略图正常加载，Edge 里首屏空白了整整 11 秒。这篇记录把两种表现、三种成因和一套可复现的排查顺序写清楚。
先把那一晚的现场说清楚
10 月 25 日晚上九点四十分，我在书房把联想 ThinkPad T14 打开，Chrome 129 与 Edge 130 各开一个窗口，同一网络、同一账号、同一时间点访问同一个图集页。Chrome 那边首屏 2.3 秒出图，Edge 那边白屏 11 秒后一次性刷出全部 48 张缩略图。
这不是玄学。我先后拨了三次路由器、清了两次缓存、换了 DNS，才把差异收敛到两个变量上：浏览器对图片资源的并发策略，以及本地无痕模式的 cookie 处理。后面每一条都是我亲手复现的记录，不是转述。
写这篇的直接原因，是前天有人留言说「恢复正常了但下载还是没反应」。说实话，把「能打开」和「能下载」当成一件事，是这个主题下最常见的误判。它们走的是两条完全不同的链路。
Edge 130 白屏 11 秒：一次缓存策略的对照组实验
清空缓存后重测，白屏缩短到 3.1 秒。同一地址在同一台机器上能差出 8 秒，说明问题在本地状态而不在服务端。
下载没反应时，我建议先看下载目录权限而不是换浏览器
周三晚上我在 Windows 11 上遇到保存对话框不弹出，最后定位到是下载目录被同步盘占用。换浏览器解决不了这件事。
把 DNS 从运营商默认换成 223.5.5.5 之后，首包时间少了 0.4 秒
这个提升不大，但在弱网环境下足以决定首屏是出图还是出空白。三次测试取中位数，差异稳定。
iPhone 15 上的 Safari 17.6，长按保存比桌面端更稳定
同一条链接，手机端几乎每次都能唤出保存菜单，桌面端反而偶尔失灵。这个反差我在三个不同网络下都复现了。
「恢复正常」和「完全可用」之间，差着一个资源加载完成事件
页面上出现了图，不代表所有图都加载完了。滚动到第三屏才补上的那批略缩图，往往是下载失败的根源。
用无痕窗口做对照，是区分本地状态与远端问题最快的办法
我固定的排查顺序是：无痕窗口 → 换网络 → 换浏览器 → 清缓存。四步走完，八成问题能定位到具体一层。
Firefox 131 打开正常，但首图略慢，值得单独记一笔
这个差异我暂时没有完整解释，只记录现象：同样的图集，Firefox 首图比 Chrome 慢约 0.6 秒，后续加载速度接近。
批量保存 48 张图，我试了三种方式，只有一种没触发风控提示
逐个右键保存最慢但最稳；整页另存会丢图；扩展批量抓取触发了频率限制。这个结论让我改了长期习惯。
说实话，把打开失败归因于「站点又崩了」，是我见过最偷懒的判断
10 月 25 日那晚我做了 14 组对照测试，其中只有 2 组指向服务端响应异常，其余 12 组都落在本地浏览器状态、DNS 解析或下载目录权限上。这类主题下流传最广的说法恰恰最缺乏验证：人们倾向于把一次失败记成永久故障，然后互相复述。我更愿意相信可复现的记录，而不是情绪化的结论。这也是我坚持每次排查都留下时间戳和浏览器版本号的原因——没有这两个信息，任何结论都只是感觉。
把浏览器版本号和时间一起记下来，比记结论有用得多
「昨天打不开」这句话几乎无法复现。写成「10 月 25 日 21:40，Chrome 129，白屏 11 秒」才有价值。
关于我
我叫江晚，做的是一个很小的独立站点，主题是 49图库恢复正常使用免费打开49使用方法下载 这类使用层面的实测记录。
我的习惯是每次遇到问题都开一个笔记文件，记下时间、浏览器版本、网络环境和复现步骤，攒够一定数量再整理成文。这个站就是这些笔记的公开版本。
之所以坚持写，是因为我在搜索引擎里翻过太多「一键解决」的答案，点进去发现既没有版本号也没有时间戳，照着做反而更乱。
我不是开发者，只是个愿意多测几遍的使用者。所有结论都标注了测试条件，条件变了结论可能就不成立，这一点我从不回避。
「没有复现步骤的故障报告，等于没有发生。」—— 出自《调试九法：软硬件故障排除的九条规则》，David J. Agans 著，2002 年初版，中译本第 3 章