Arc 之后：浏览器迁移要保住标签背后的工作

Arc 在 10 月 22 日的公告中，将桌面版停止运行日期定为 2026 年 12 月 22 日，并提供迁往 Dia 或向其他浏览器导出标签链接的路径。官方公告。

对于已经把浏览器搭成工作环境的人，实际问题是这套环境还能重建多少。导出成功能够证明某些数据已经搬走；要判断迁移是否可用，还需要重新打开工作，知道应该从哪里继续。本文讨论的是这一差别，属于编辑分析，并非对 Arc、Dia 或其他浏览器做过实测后的性能结论。

链接周围的关系

设想一名研究者同时查看一家公司的最新披露、较早版本的文件，以及记录假设的表格。迁移后，每一个网址都可能仍然有效。但真正有用的工作单元还包括：哪份披露是当前版本，为什么保留旧文件，哪张表格对应这次比较，以及还有哪个问题没有解决。文件夹名称可能保存了一部分关系，其余部分则可能只存在于使用者的记忆中。

书签数量无法衡量这些关系。丢失一组随手收藏的阅读材料，与丢失一项未完成研究的上下文，可能让数量减少同样多，恢复成本却相差很大。反过来，若已辨认过时重复项，并为保留材料加上清楚标签，更小的集合也可能更有用。因此，没有充分理由把数量完全相等设为通用验收条件。

迁移的第一个决定，应当是哪些内容必须保持可理解。主要访问熟悉网站的人，也许只需要可靠入口；同时管理多个项目的人，则可能需要一份简短项目索引：这组资料服务什么问题，哪份文档具有权威性，上一次做到哪一步。索引可以放在权限合适的文档中，而不必依附于某个浏览器独有的视觉布局，也不需要复制每一页内容。

通用格式承担的任务有限

Google 的文档说明，Chrome 支持 HTML 书签导入与导出。Chrome 文档。这是这类信息的一条实用交换路径，但仅凭它，不能证明另一款产品导出的每个字段都兼容，也不能证明完整的项目组织方式都能从中恢复。

这条边界值得说清。一个文件可以被读取，导入器却只解释其中一部分；目标浏览器也可以显示所有网址，但整理方式已让原使用者难以理解。这两种结果都不能直接证明源产品丢失了数据，问题也可能在于两套组织模型之间的映射。把映射问题找出来，才有可能补救；笼统地说“迁移失败”，提供不了足够线索。

实际迁移时，小规模、有代表性的试迁，比立即导入庞大集合更能说明问题。可以选择一个活跃项目、一个仍有价值的旧项目，以及一项使用独立工作身份访问的资源，并明确每个样本要验证什么。链接能打开，只能说明入口可达，不能说明正在使用正确的账户和项目上下文。这些是建议的检查方法，不是在指控任何浏览器会错误处理账户。

重新做一次昨天的工作

更有价值的演练，应从使用者最近完成过、能够辨认结果的任务开始。能否找到权威来源，与相关的另一份材料比较，并在不重建整个环境的情况下继续下一步？记录哪些地方需要人工补回关系，以及这些缺口在忙碌时是否会造成影响。只打开目标浏览器首页的测试，回答不了这些问题。

选样的重要性高于轻松链接的数量。若干公共新闻网站的书签全部正常，也无法覆盖那个必须切换特定账户的项目；同样，一个特殊项目遇到困难，也不足以证明所有日常工作都无法进行。应把常规工作与例外分开，再决定哪些缺口必须在设为默认浏览器之前处理。

反复试导入也有成本。Mozilla 说明，Firefox 会把 HTML 导入的书签加入已有书签，因此可能产生重复。Firefox 文档。重试之后数量增加，值得解释，而不能自动当作恢复更完整的证据。源数据快照和试迁结果应保持可区分，在改动原有集合之前，应使用接收产品支持的备份与恢复方式。

便利与独立可以同时保留

针对特定接替产品设计的迁移路径，可能比通用导出更能保留熟悉的组织方式。当连续工作很重要时，选择这种路径可以是合理决定。更中性的表达方式则承担另一项任务：让使用者在离开某个产品界面后，仍能理解手中的材料。两种方式可以互补，前提是实际检查那份中性副本，而不是假定有副本就已足够。

维护副本也并非免费。它可能过时，增加一个保存敏感项目链接的位置，也会带来轻度用户根本不需要的维护负担。合理范围应是那些一旦失去上下文，恢复代价就会很高的材料。存放权限应符合链接所透露的信息，不要把迁移变成无差别分享材料或导出凭据的行动。

对产品设计来说，更有意义的变化是把可迁移性描述成使用者能够验证的结果：哪些对象转移了，哪些关系保留了，哪些功能需要重新搭建。使用者也因此可以按自己的工作验收，而不必依赖模糊的完整性承诺。本文查阅的文档没有给出真实迁移成功率，也不能证明哪款目标浏览器适合某个人。剩余的不确定性，需要在原环境仍可用时，通过范围明确的真实演练来消除。

最终值得保住的东西并不夸张：下次界面再变化时，资料的主人仍然明白这些材料意味着什么，也知道如何接着做下去。