Arc 之後：瀏覽器遷移要保住分頁背後的工作

Arc 在 10 月 22 日的公告中，將桌面版停止運作日期定為 2026 年 12 月 22 日，並提供遷往 Dia 或向其他瀏覽器匯出分頁連結的途徑。官方公告。

對於已經把瀏覽器搭成工作環境的人，實際問題是這套環境還能重建多少。匯出成功能夠證明某些資料已經搬走；要判斷遷移是否可用，還需要重新打開工作，知道應該從哪裡繼續。本文討論的是這項差別，屬於編輯分析，並非對 Arc、Dia 或其他瀏覽器做過實測後的效能結論。

連結周圍的關係

設想一名研究者同時查看一家公司的最新揭露、較早版本的文件，以及記錄假設的試算表。遷移後，每一個網址都可能仍然有效。但真正有用的工作單元還包括：哪份揭露是目前版本，為什麼保留舊文件，哪張試算表對應這次比較，以及還有哪個問題沒有解決。資料夾名稱可能保存了一部分關係，其餘部分則可能只存在於使用者的記憶中。

書籤數量無法衡量這些關係。失去一組隨手收藏的閱讀材料，與失去一項未完成研究的脈絡，可能讓數量減少同樣多，恢復成本卻相差很大。反過來，若已辨認過時重複項，並為保留材料加上清楚標籤，更小的集合也可能更有用。因此，沒有充分理由把數量完全相等設為通用驗收條件。

遷移的第一個決定，應當是哪些內容必須保持可理解。主要造訪熟悉網站的人，也許只需要可靠入口；同時管理多個專案的人，則可能需要一份簡短專案索引：這組資料服務什麼問題，哪份文件具有權威性，上一次做到哪一步。索引可以放在權限合適的文件中，而不必依附於某個瀏覽器獨有的視覺配置，也不需要複製每一頁內容。

通用格式承擔的任務有限

Google 的文件說明，Chrome 支援 HTML 書籤匯入與匯出。Chrome 文件。這是這類資訊的一條實用交換途徑，但僅憑它，不能證明另一款產品匯出的每個欄位都相容，也不能證明完整的專案組織方式都能從中恢復。

這條界線值得說清。一個檔案可以被讀取，匯入工具卻只解讀其中一部分；目標瀏覽器也可以顯示所有網址，但整理方式已讓原使用者難以理解。這兩種結果都不能直接證明來源產品遺失了資料，問題也可能在於兩套組織模型之間的對應。把對應問題找出來，才有可能補救；籠統地說「遷移失敗」，提供不了足夠線索。

實際遷移時，小規模、有代表性的試遷，比立即匯入龐大集合更能說明問題。可以選擇一個活躍專案、一個仍有價值的舊專案，以及一項使用獨立工作身分存取的資源，並明確界定每個樣本要驗證什麼。連結能打開，只能說明入口可達，不能說明正在使用正確的帳戶和專案脈絡。這些是建議的檢查方法，不是在指控任何瀏覽器會錯誤處理帳戶。

重新做一次昨天的工作

更有價值的演練，應從使用者最近完成過、能夠辨認結果的任務開始。能否找到權威來源，與相關的另一份材料比較，並在不重建整個環境的情況下繼續下一步？記錄哪些地方需要人工補回關係，以及這些缺口在忙碌時是否會造成影響。只打開目標瀏覽器首頁的測試，回答不了這些問題。

選樣的重要性高於輕鬆連結的數量。若干公共新聞網站的書籤全部正常，也無法涵蓋那個必須切換特定帳戶的專案；同樣，一個特殊專案遇到困難，也不足以證明所有日常工作都無法進行。應把常規工作與例外分開，再決定哪些缺口必須在設為預設瀏覽器之前處理。

反覆試匯入也有成本。Mozilla 說明，Firefox 會把 HTML 匯入的書籤加入既有書籤，因此可能產生重複。Firefox 文件。重試之後數量增加，值得解釋，而不能自動當作恢復更完整的證據。來源資料快照和試遷結果應保持可區分，在改動原有集合之前，應使用接收產品支援的備份與恢復方式。

便利與獨立可以同時保留

針對特定接替產品設計的遷移途徑，可能比通用匯出更能保留熟悉的組織方式。當連續工作很重要時，選擇這種途徑可以是合理決定。更中性的表達方式則承擔另一項任務：讓使用者在離開某個產品介面後，仍能理解手中的材料。兩種方式可以互補，前提是實際檢查那份中性副本，而不是假定有副本就已足夠。

維護副本也並非免費。它可能過時，增加一個保存敏感專案連結的位置，也會帶來輕度使用者根本不需要的維護負擔。合理範圍應是那些一旦失去脈絡，恢復代價就會很高的材料。存放權限應符合連結所透露的資訊，不要把遷移變成無差別分享材料或匯出憑證的行動。

對產品設計來說，更有意義的變化是把可遷移性描述成使用者能夠驗證的結果：哪些物件轉移了，哪些關係保留了，哪些功能需要重新搭建。使用者也因此可以按自己的工作驗收，而不必依賴模糊的完整性承諾。本文查閱的文件沒有給出真實遷移成功率，也不能證明哪款目標瀏覽器適合某個人。剩餘的不確定性，需要在原環境仍可用時，透過範圍明確的真實演練來消除。

最終值得保住的東西並不誇張：下次介面再變化時，資料的主人仍然明白這些材料意味著什麼，也知道如何接著做下去。