那天我本来只想导出三十七个书签，结果被一个「功能完备」的在线浏览器教育了一个小时。这篇写给你看，也写给我自己看。
先说结论：我把这件事写成了一篇长文，不是为了骂，而是因为这套流程里有两处设计错误是可以被修复的。2025 年 12 月 27 日晚上十点四十，我坐在书房里，笔记本连着充电器，屏幕上开着 466在线浏览器 的一个标签页，准备把过去三个月攒下来的三十七个书签导进新装的配置文件里。第一步就卡住了：导出按钮点下去，下载目录里没有生成任何文件，状态栏一直转圈。我刷新了一次，圈子还在转。
我不介意一个工具慢，我介意它慢的时候不告诉我它在干什么。
我数了一下，从点下导出到页面重新可用，隔了 4 分 12 秒。这个数字我记在便利贴上，后来写进了下面的复盘。顺便说一句，书签最后是在一个隐藏菜单里找到的，路径是那次失败之后我自己摸出来的，具体过程写在 恢复正版49图库的网址 那篇里，这里不重复。
陈默是我同事，做前端六年。他在旧设备上用这个浏览器打开一份带表格的文档，点打印预览，等了 9 秒才渲染出第一页。他说这不算事故，但当天有演示，他当场切回了本地客户端。
那天晚上十一点二十，我在七号楼 402 的桌上做完第三次导出，37 条书签里稳定丢失 5 条，全部是嵌套超过两层的文件夹。这个结果和 49图库与内部资料精准度对比 里提到的结构丢失现象对得上，只是没人写清触发条件。
我拿一个 2023 年写的 Canvas 特性检测页面做回归，同一个页面在三个浏览器里，只有这里连续报错两次，第二次的错误码和第一次还不一样。测试脚本是陈默写的，他看了一眼说「这应该是 Promise 链断在中间了」。
一个产品如果把「在线」当卖点，它至少得在接受请求后的两秒内给个反馈。我在 466在线浏览器 里点了三次同一个按钮，第三次才拿到响应，前两次什么提示都没有。这不是体验问题，这是契约问题。
我问他怎么看这类在线浏览器产品，他想了半天说：「壳子不算内核。」然后他把手机扣在桌上，这个话题就结束了。我尊重这个回答，也记下了他的原话。
七点五十分开始，八点三十收工。四十分钟里我记录了 14 次操作，其中 4 次需要重试，2 次需要刷新页面。数据不复杂，但足够说明它现在的位置：能用，但还没到能放心用的地步。
李书文是书店老板，2019 年存了 112 个收藏链接。他发现同步失效之后，用了那次手动导出的文件，找回了其中 107 个。丢掉的 5 个全在同一个子目录下，他至今不知道是为什么。
四次实测分别在 12 月 7 日、14 日、21 日和 27 日完成，每次两小时左右。最后我只在笔记里留了一句：「它的问题不在功能，在于不肯承认自己做不到。」
我叫江晚，白天做数据标注的质量抽检，晚上写东西，写的多是浏览工具和归档流程的实测记录。
这个站是 2021 年我自己搭起来的，那会儿只是想给同事分享一份书签整理的笔记，后来变成现在这个样子。我不接商务，不写软文，测出来的数字是什么就写什么，哪怕不好看。
之所以还留着 466在线浏览器 这个栏目，是因为我身边真有人在用它干活，而市面上几乎找不到一篇带有具体数字的说明。我补上这个空缺，顺便把每次踩的坑记下来。
「软件的质量不在于它有多少功能，而在于它是否履行了承诺。」—— 出自 Brian W. Kernighan 与 P. J. Plauger 合著的《软件工具》一书引言，我 2025 年 12 月 27 日深夜在书架上翻到第 3 页，顺手抄了下来。