Arc 浏览器为什么关闭？原因分析与迁移建议

Arc 浏览器将于 2026 年 12 月 22 日关闭。 The Browser Company 给出的直接原因是：浏览器安全需要持续的专门投入，接下来工程和安全团队会集中到 Dia。这次已经有明确的停止服务日期。官方告别页写明，macOS 和 Windows 版届时将停止工作。

对把日常工作放在 Arc 里的人来说，导入数据只解决了一部分问题。公告下，一位 Reddit 用户 danroesser 提到自己的专业工作流受到影响，并表示愿意付费继续用 Arc。这是个人意见，却说中了迁移真正难的地方：网址能带走，已经习惯的工作方式能否接着用？

下面先解释关闭的原因，区分官方事实与分析判断，再给出迁移步骤。如果你既想保留垂直标签管理，也希望 AI 能结合网页和文件帮助工作，Tabbit Browser 可以进入试用清单。先拿一个项目验证，再决定是否更换默认浏览器。

先记住这几件事

• macOS、Windows 版 Arc 将于 2026 年 12 月 22 日停止工作，应按这个日期安排迁移。

• 官方当前的直接解释是安全维护与团队投入转向 Dia。更早的产品原因还包括采用门槛、增长目标和架构取舍。

• Dia 是官方指定的接替产品。公告说明其浏览器功能免费，AI 可选，并已提供 Windows 迁移路径，不能再照搬“只有 Mac”的旧判断。

• Arc Search 有独立时间表。iOS 会保留精简浏览器，Android 在 12 月完全弃用。

• 先保留网址和项目记录，再检验替代产品能否接住日常工作。Tabbit 适合纳入网页调研与 AI 工作的验证，但迁移细节需要单独核对。

Arc 关闭时间表

来源为 Arc 官方时间表与 FAQ，核对于 2026 年 10 月 23 日。官方同时说明，从 12 月 22 日起无法再识别或检索 Arc 用户数据来处理数据请求。因此，“30 天内删除”不意味着可以等到明年再导出。

在亚洲时区，X 帖子显示的日期可能是 10 月 23 日；官网将公告起点写为 10 月 22 日。这是时区显示差异，12 月的截止日并无变化。

Arc 为什么关闭？要分三层看

直接原因：工程和安全投入集中到 Dia

用户提供的官方 X 帖子明确说，维护浏览器安全需要持续投入，在 AI 时代要求还会增加。公司认为 Dia 从基础设计上更适合当前安全标准，因此把工程和安全团队的重心集中到 Dia。

这能证明资源投入和产品优先级发生了选择。公告没有披露一个导致这次关闭的新漏洞，也没有说现有 Arc 安装都遭到入侵。不能从“安全”两个字推导出一次未经公布的事故。

对用户而言，关键是浏览器明天还有没有团队维护。今天能打开网页，只能证明今天还能用。过渡期继续使用可以理解，但把截止日后的 Arc 当作稳定、持续支持的主力工具，就与当前公告冲突了。

产品原因：重度用户喜欢，不等于能满足公司的增长目标

更早的解释见 2025 年 5 月 27 日致 Arc 用户的公开信。公司承认，Arc 赢得了一批很投入的用户，但对更多新用户来说，需要重新学习的概念太多，能立即感受到的收益又不够明显。

公开信给出的三个数字经常被引用：日活用户中，5.52% 经常使用不止一个 Space，4.17% 使用 Live Folders，0.4% 使用 Calendar Preview on Hover。这是公司在 2025 年公布的行为统计，本文没有可复现的原始数据。尤其要注意，5.52% 衡量的是“经常使用多个 Space”，不能改写成“只有 5.52% 的人需要工作区”，更不能据此说其余用户不喜欢 Arc。

这里的分析判断是：Arc 可以是一款让特定用户满意的工具，同时没有达到公司期待的大众产品规模。用户觉得侧边栏、固定标签和稳定习惯已经足够好；公司却希望更多人改变默认浏览器。双方评价的是不同问题。

所以，“为什么不收费继续做”是合理追问，但目前只能确认部分用户愿意付费。它不足以证明一套完整的收入模型，也不能证明公司愿意经营规模更小的付费产品。现有资料同样不支持把这次关闭描述为破产。

架构与战略原因：公司选择重建产品，并持续投入 Dia

2025 年的公开信还把性能和架构限制列为另建 Dia 的理由。这是团队对自身工程选择的解释，不能直接当成独立性能测试。

现在的告别页进一步声称，Dia 的稳定性、速度和安全性已超过 Arc，但页面没有提供可复现的完整测试方法。对个人用户更有价值的验证是：打开一个真实项目、查找固定页面、登录常用工作系统、运行关键扩展，是否顺手。阅读 Dia 与 Arc 的对比时，也要以最新官方公告覆盖旧的可用性信息。

Atlassian 在 2025 年 9 月公布收购协议时，已把愿景写在 Dia 和知识工作上。这说明投入方向持续朝 Dia 集中，但不能据此断言“收购方命令 Arc 关闭”。Arc 转向 Dia 的决定在收购公告之前几个月就已公开，不能倒置因果。

为什么“数据导入成功”还不够

这次官方给出的 Dia 迁移方案相当具体。公告说，macOS 和 Windows 上都能导入密码、书签、扩展、历史、标签等支持的数据；Spaces 变成 Profiles，Folders 变成 Tab Groups。页面还列出垂直 Sidebar、Pinned Tabs 和 Split View，并明确浏览器功能免费，AI 可选。

因此，不能为了推荐其他产品，把 Dia 写成“必须花钱买 AI 才能浏览”，或继续说它没有 Windows 版本。不过，支持导入的数据类别相似，也不代表所有操作体验一致。

设计师 Andreas Storm 在回复中要求 Dia 提供可选的 Peek。另一位用户 Drin 则提出了自己对 Windows 体验和同步的顾虑。这些反馈反映用户当时关心什么，不能单独当作当前产品缺陷的完整清单。

迁移之前，写下每天最常做的五个动作。比如切换工作身份、预览链接、用快捷键定位标签、运行某个扩展、恢复昨天的项目。对照这份清单试用类似 Arc 工作区的浏览器，才能判断熟悉的工作方式是否真正接续。

网页调研与 AI 工作，可以试试 Tabbit Browser

如果你喜欢 Arc，是因为它让同一项目的资料始终在眼前，那么 Tabbit 值得验证。当前国际官网说明，可以把网页、截图、选中文字和本地文件作为 AI 上下文；国内官网也展示了垂直标签与智能分组。国内版和国际版的平台、模型与会员权益应按安装的版本分别核对。

可以拿一个有多篇产品资料和一份本地需求文件的项目来验证。先打开这些页面的副本，整理成便于管理的分组，再把相关网页与文件引用到对话中，要求输出带来源和待核实事项的对比。目标是一份能检查、能另存的工作笔记。这里给出的是依据官方能力设计的操作方案，没有冒充作者亲测或速度对比。

请对照附件需求，比较我引用的产品页面。
逐项列出满足需求的证据、来源网址，以及资料没有说明的部分。
不要补全未知事实，最后列出需要人工核实的问题。

Tabbit 功能介绍解释了上下文和任务的使用方式；AI 标签整理对应分组。如果只是窗口太乱，也可以先照着标签过多的整理方法处理。AI 的分组与回答都需要复核；模型请求可能将你选定的上下文发送给服务提供方，使用工作资料前应检查内容与隐私设置。

迁移边界也要说清楚：本次没有验证 Tabbit 能直接导入 Arc，或保留 Arc Spaces、Peek 与全部快捷键。先导出网址，在 Tabbit 中重建一个项目，按第二浏览器试用的方法检查一遍。能完成真实工作，再决定是否设为默认。

先导出，再选下一款默认浏览器

官方当前的导出步骤已经给出明确入口：

1. macOS 打开 Arc → Settings → Advanced → Export Data。

2. Windows 用 Ctrl+, 打开设置，在 Advanced 中找到 Export Spaces and tabs → Export Data。

3. 把文件保存在自己能控制的位置，打开检查重要网址和项目结构是否有记录。

4. 手机标签单独从 Arc Search 设置中导出，尽量在移动端登录和同步关闭前完成。

5. 在替代浏览器里重开一个小项目，验证登录、必要扩展、快捷键、下载和独立保存工作成果的方式。

官方把迁往其他浏览器的导出描述为网址列表，不要默认其中也有密码、登录会话或未提交的表单。它们需要单独处理。Dia 的专用导入是另一条路径，不能据此推断其他浏览器也具备同样的迁移能力。

如果项目只存在于打开的标签里，另外保存一份书签或项目文档。浏览器会话管理工具可以辅助保存工作集，但仍要在 Arc 关闭前检查副本。更换应用时，项目本身应该能够找回。

按需要保留的工作方式选择

更完整的候选清单可以参考 Arc 替代浏览器指南，但各产品现状要以最新官方信息为准。标签组织和 AI 辅助是两项需求，应该分别验证。

公开资料支持的结论是：Arc 的关闭，是公司在增长与架构判断之后，继续把维护和产品投入集中到 Dia 的结果。对用户最有用的行动，是先让资料可以迁移，再用真实项目验证下一款浏览器，并在 12 月 22 日前完成。如果你的项目经常需要跨网页和文件收集、比较信息，可以用一份副本试用 Tabbit，再由本页下方的下载入口开始。

Secholar.L

Tabbit 增长与内容

Secholar.L 专注 AI 浏览器与 Agent 工作流的实操写作,基于真实调研对比工具,引用可验证的一手来源。