Arc 浏览器定于12月22日停运：用户需核查迁移与后续安全更新

The Browser Company 已在 Arc 官网公布停运时间表：2026 年 12 月 22 日，macOS 与 Windows 版 Arc 将停止工作，Arc 账号被停用，账号内的个人数据会在 30 天内删除。受影响的不只是把 Arc 当日常浏览器的个人用户，还包括需要盘点终端软件存量的运维与安全团队——一款仍在生产环境中运行的浏览器停止维护，意味着它不再进入后续的安全更新通道。

三阶段停运：先停注册，再断同步，最后停用

官方公布的安排分为三个阶段，边界比较清晰：

Arc 与多数浏览器的一个关键差异是必须登录账号才能使用。这也决定了它无法像某些停更软件那样“冻结版本继续跑”：账号停用之后，桌面端连进入界面都做不到，切换不是可选项，而是时间问题。

厂商给出的理由是维护成本。官方声明称，保持浏览器安全需要持续且专注的投入，而这种投入在 AI 时代只会继续增加；Dia 从一开始就按当今的安全标准构建，工程与安全团队此后将专注于此。Arc 自 2025 年转入维护状态后，仅接收安全更新与问题修复，如今这条通道也一并关闭。

停运真正终止的是安全维护

需要区分两件事：产品功能停止演进的后果在可控范围内，安全更新终止的后果则会随时间累积。

浏览器是终端上暴露面最大的应用之一，渲染引擎、脚本引擎、网络栈的缺陷修复通常随版本更新下发。停更之后，即使上游发现并修复了问题，Arc 也不会再获得对应补丁。按浏览器维护的一般规律，这类风险不会在停运当天立刻显现，而是在停运后的数月内逐步上升，且不会伴随任何提示。这一点属于基于维护模式的推断，官方公告并未给出具体的漏洞结论，不宜据此渲染为“立即失守”。

Dia 能否承接安全需求，目前主要依据厂商自述。官方称 Dia 在速度、稳定性和安全性基准测试上已超越 Arc，但独立第三方验证尚未见到；Arc 是否会开源也仍无定论，CEO 曾表示 Arc 构建在专有内部 SDK（ADK）之上，而 ADK 同时是驱动 Dia 的核心，开源 Arc 意味着公开 Dia 的知识产权。这两点都应视为待观察项，而不是既成事实。

迁移之前值得逐项核对的清单

官方提供的迁移路径是导入 Dia：密码、书签、扩展程序和历史记录可迁移，Spaces 对应 Dia 的 Profiles，文件夹更名为固定标签组，垂直标签栏作为可选侧边栏保留，Arc 原有功能在 Dia 中保持免费，AI 功能可选。但“能导入”与“导入后安全”是两回事，建议按下面的顺序核对：

• 先导出再迁移：最新版 Arc 已提供数据导出，覆盖密码、书签、扩展程序、历史记录、Spaces、文件夹与标签组。导出文件往往是明文或弱加密的中间产物，迁移完成后应立即删除，并清理临时目录与回收站。
• 核查账号与凭证：确认 Arc 账号绑定的邮箱仍可访问，以便接收停用通知；迁移后检查是否有遗留的登录会话、OAuth 授权仍指向旧账号。
• 核对扩展来源与权限：扩展本身能在新浏览器中继续使用，但权限范围不会自动收紧。迁移时适合顺手清理长期未使用、来源不明或权限过宽的项目。
• 验证关键站点可用性：银行、企业内部系统、依赖客户端证书或硬件密钥的站点，需要在 Dia 中实测，而不是假定兼容。
• 确认数据删除窗口：账号数据在 12 月 22 日后 30 天内删除，此前是最后的取回机会。

企业环境的处置顺序

对负责终端治理的团队，这件事更接近一次有时限的软件下线，而不是一次浏览器推荐。

第一步是盘点。从资产清单、终端管理平台和软件安装上报中拉出 Arc 的存量安装，区分仍在活跃使用与已闲置未卸载两类，后者往往是遗漏项。第二步是识别依赖。个别团队可能把 Arc 的 Spaces 当作工作流的一部分，直接替换会打断业务，需要单独沟通迁移窗口。

第三步是评估替代方案是否满足既有约束。若考虑迁移到 Dia，需要确认它是否进入组织的允许软件清单，AI 功能能否按策略关闭或限制，扩展安装是否受统一管控，以及数据留存与合规要求是否匹配；若不允许，应直接指定已批准的浏览器作为替代，而不是留待员工自行选择。

第四步是收尾。统一导出并归档必要数据，撤销 Arc 账号相关的授权，从镜像与软件分发中移除安装包，并设定一个明确的时间点完成卸载核查。整个过程建议保留一份处置记录，便于后续审计时说明迁移依据。

最后需要提醒的是，以上安排以官方公告为准。停运时间表、数据删除窗口和 Dia 的功能对应关系都可能随公告更新调整，涉及批量处置前应重新核对一次官方页面，不要仅凭二手转述执行。