主文 · 实测
2026-05-09 · 江晚
我先说场景。5 月 8 日 21:40，我把 iPad 竖在茶几上，用 Safari 打开图库首页；同一分钟，ThinkPad X230 上的 Firefox 登录了同一个账户；手机是 Redmi Note 12，用 app 内的内嵌浏览器。三个会话，同一份资料，我要看的是“打开”这个动作在三端是否指向同一个位置。
记录很克制：平板端加载了 47 张缩略图，笔记本端 46 张，手机端 48 张。差异不是内容缺失，而是懒加载触发的时机不同。我把这个差异记在便签上，编号 B-03。真正影响“同步”的不是数量，而是滚动位置是否被记住——三端里只有笔记本端恢复了上次的浏览位置，另外两端回到了顶部。
我的观点写得直白一些：多数人以为多设备同步的核心是账号，其实核心是会话状态的持久化粒度。图库类站点如果只同步“收藏”而不同步“读到哪”，那它解决的是搬运问题，不是连续性问题。这一点上，49图库目前的实现是半成品，但方向没错。相关的维护背景可以对照 4949资料图库资料库维护 那篇里提到的索引重建节奏。
我还做了一次反向验证：在手机上清除缓存后重新打开，图库资料仍然可见，说明“免费打开”这一层没有绑定本地存储；但收藏列表空了，需要重新拉取。也就是说，免费打开是服务端行为，同步是账户行为，两者是两条独立的链路——这个区分，是我那晚最实在的收获。
对照
22:05，我在 X230 上把 Firefox 的增强跟踪保护调到“严格”，图库首屏的缩略图请求被拦了 3 个。切回 Safari，同样的页面完整呈现。这条差异我记在 B-07，它说明“免费打开”对浏览器策略敏感。
方法
多设备同步这件事，我习惯拿 QQ 网页版的登录态做参照物：它把“在线”和“消息已读”拆得很清楚。图库资料要的是同一套思路——打开状态与阅读进度分开存，才不会互相拖累。这个类比在 22:30 前后的笔记里出现了两次。
细节
平板端 47 张、手机端 48 张：那 1 张差异的来源
第 48 张是页尾的推荐位，手机端因屏幕短，提前触发了懒加载。我把这个数字写进便签，是因为它提醒我：同步的“一致性”在移动端天然会被视口尺寸扰动，不能简单按数量对齐。
观点
我的判断：同步做得好不好，看它记不记得你读到第几屏
收藏是搬运，进度是连续。一个图库站点如果只做到了前者，说“多设备同步”就有点勉强。这话我在文末又重复了一遍，因为它是整晚测试里唯一站得住的批评。
维护
据站点公告，5 月 7 日 02:00 到 04:30 有过一次索引重建。我 5 月 8 日晚的测试赶在重建之后，首屏时间在笔记本端是 1.4 秒，平板 1.9 秒，手机 2.6 秒。慢的那一端是网络，不是服务。
引用
陈默在 4 月的一次讨论：同步的边界应该写进产品说明
陈默是做前端的朋友，4 月 19 日我们在五道口一家咖啡馆聊过这事。他说：“用户不介意你不同步，介意的是你没说清楚哪些不同步。”这句话我原样抄进了笔记，因为它比任何评测指标都直。
清单
我那晚留下的 5 条待验证项
一、断网重连后收藏是否回填；二、换设备后滚动位置是否保留；三、免费打开是否有次数上限；四、清理浏览器数据后的行为；五、夜间低峰期加载是否更稳。前两条已验，后三条留到 5 月 10 日。
指南
那份指南把“多设备同步”归在账户功能下，措辞谨慎，只承诺收藏与历史记录的迁移，未承诺阅读位置。这种克制其实是对的，比含糊地写“全面同步”要负责。
后续
5 月 10 日计划：把断网重连这一项补完
我打算在 5 月 10 日上午 10 点，用飞行模式模拟断网 3 分钟，再恢复，看三端收藏是否一致回填。这个测试比首屏时间更能说明问题，因为它直接指向“状态存在哪”这个底层问题。