Ghostty：HashiCorp 创始人的”不做选择”终端，与它 18 年后告别 GitHub

终端模拟器是开发者每天盯最久、却最容易被忽视的一层软件。过去十几年，这个品类被切分成两个阵营：一边是追求极致性能、但功能简陋或 UI 粗糙的方案；另一边是功能丰富、却靠 Electron/Web 技术栈换来体积与延迟的方案。你几乎总要在”快、功能全、原生体验”三者里挑两个。Ghostty 是 HashiCorp 创始人 Mitchell Hashimoto 离开公司后，用业余时间做的一款跨平台终端，目标是把三者同时拿下——官网当前版本为 1.3.1。本文基于 Ghostty 官方文档与作者本人博客，分析它到底兑现了多少，以及它在 2026 年 4 月宣布”离开 GitHub”背后的开源治理话题。

一、背景：为什么是 HashiCorp 创始人来做终端

Mitchell Hashimoto 并不是普通独立开发者：他是 Vagrant、Packer、Consul、Terraform 等一系列基础设施开源项目的作者，也是 HashiCorp 的联合创始人。他在博客里自述是”GitHub 用户 1299 号”，2008 年 2 月注册，此后 18 年几乎每天打开 GitHub——甚至度蜜月时妻子还没醒就想提交一个 commit。

正因为他是终端的重度用户（写基础设施工具、长期 SSH、跑开发环境），他对现有终端的”三选二”困境有切身体会。Ghostty 官网 about 页明确写道：他不声称 Ghostty 在任何一个维度上”最好”，只是想做一个在速度、功能、原生 UI 三个维度上都”拿得出手”的终端，而不是在其中两维做到极致、第三维凑合。

需要先泼一盆冷水：Hashimoto 在 about 页亲自声明，Ghostty 是他的”热情项目（passion project）“，是业余时间的心血，不是任何人的全职工作，维护节奏与响应速度都要按这个预期来。

二、是什么：一个被拆成”核心 + 外壳”的终端

Ghostty 的技术架构是它最值得讲的部分。它把整个产品切成两层：

• libghostty：跨平台、C ABI 兼容的核心库，用 Zig 编写，负责终端仿真（VT 解析）、字体处理与渲染。官网称它是”零依赖”的 C/Zig 库，不仅服务 Ghostty 自己，也希望其他终端项目或想内嵌终端的应用直接复用。
• 各平台 GUI 外壳：macOS 端用 Swift 编写，基于 AppKit 与 SwiftUI；Linux 端用 Zig 编写，基于 GTK4 的 C API。两者都只是链接 libghostty 的 C API，在其上做原生窗口、标签、分屏等 UI。

这个”核心与 UI 分离”的结构，正是它能同时做到”原生”和”跨平台”的关键：终端仿真逻辑只写一份（Zig），而每个平台的窗口部件都用该平台自己的原生控件（标签页、分屏、错误弹窗），而不是像很多终端那样用自绘控件或纯文本 TUI。

三、功能：原生体验到底接了哪些系统能力

Ghostty 把功能分成”终端内程序能用的”和”终端本身的”两类。

终端程序能力（运行在终端里的应用能调用的）包括：Kitty 图形协议、亮/暗模式切换通知、超链接等。这让 Neovim、Zellij 这类 TUI 应用能比在其他终端里做得更多——例如 Neovim 的同步渲染（synchronized rendering）防闪烁，就依赖终端支持对应控制序列。

终端自身能力包括：原生标签页、分屏（splits）、macOS 上的下拉式终端（drop-down terminal）、跟随系统亮暗模式自动切换主题等。macOS 端还接了 Quick Look、Force Touch、macOS 安全输入 API、重启后窗口状态恢复等系统原生 API——这些在 Linux 桌面环境里没有对等物。

配置哲学上，Ghostty 主打”零配置开箱即用”：内置默认字体 JetBrains Mono、自带 nerd fonts、内置数百套配色主题，并能随亮暗模式自动切换。官方的态度很明确——如果你只是为了”用起来”而去配置了什么非主观性的东西，欢迎提 discussion，项目会考虑把它变成默认值。

四、关键信息一览

五、性能口径：它故意不给你硬数字

“快”是终端评测里最容易引发骂战的话题。Ghostty 官方在 about 页的措辞相当克制，值得逐条拎出来：

• 它不声称自己最快，只说”目标是和最快的终端处于同一梯队”；
• 原话是”在某些 benchmark 里它更快，在另一些里更慢，但无论如何你都不该能说出 Ghostty 慢”；
• 官方承认”fast”是个含混词——启动时间、滚动速度、IO 吞吐、控制序列吞吐、帧率，是完全不同的维度，而 Ghostty 在公开首发时并没有提供系统化的 benchmark，只说未来会补上。

这意味着：网上任何”Ghostty 吊打所有终端”的说法，都超出了官方自己的声明范围。它的性能叙事目前停留在”目标同梯队 + 新用户主观反馈很明显”，而不是可复现的公开数据。

六、局限与口径：官方自己承认的边界

做这种”三栖”产品，妥协点必须说清楚：

1. libghostty 还不是稳定库。官方 note 明确：截至首次公开发布，libghostty 的 API 尚未稳定，也没有作为独立库发布；它目前只被 macOS/Linux 两个 GUI 自己使用。“欢迎其他项目基于它构建”是目标，不是现状。
2. Linux 的”原生”要打折扣。官方脚注承认：Linux 没有像 macOS AppKit 那样的统一原生工具包，GTK4 只是”最接近标准”的一个；用 Adwaita 与否，取决于你的桌面环境，“原生”与否没有定论。
3. 非全职维护。作者反复强调这是业余项目，不要按商业产品的响应速度预期它。
4. macOS 版本门槛：通用二进制要求 macOS 13 Ventura 及以上，更老的系统无法使用官方预编译包。

七、治理风波：18 年老用户为什么离开 GitHub

2026 年 4 月 28 日，Hashimoto 发表博客《Ghostty Is Leaving GitHub》，引发开源圈讨论。他给出的理由不是意识形态，而是可靠性：

• 他在博客里记录了一本”故障日记”——过去一个月里，每个因 GitHub 宕机而影响他工作的日子都画一个叉，结果”几乎每一天都有叉”；
• 写博客当天，他因为 GitHub Actions 故障，约两小时无法做任何 PR review；
• 他的结论是：如果一个平台每天阻塞你几小时，“这里不再是做严肃工作的地方”。

作为 GitHub 第 1299 号用户、18 年深度用户，他的离开被普遍解读为”AI 时代 GitHub 负载暴增、可靠性下降”的一个标志性信号——Koala 项目库的点评也提到，GitHub CTO 随后发文承认 AI coding 让平台负载”数十倍增长”。需要核对的口径是：截至本文撰写时（2026 年 9 月），Ghostty 的 GitHub 仓库（ghostty-org/ghostty）仍然公开可见、源码与 Issue/PR 仍在更新；作者当时也说迁移对象还在”商业与开源方案之间讨论”，迁离是已宣布的意图，而非已经完成的事实。

八、谁该关注

• 你是 macOS/Linux 上的重度终端用户，厌倦了 Electron 终端的延迟，又想要原生分屏/标签和现代 TUI 协议支持——Ghostty 是目前”原生 + 现代协议”路线里最受关注的候选。
• 你在做”内嵌终端”的应用，值得关注 libghostty 的演进（虽然现在 API 还不稳定，生产使用要谨慎）。
• 你是开源维护者，这篇”离开 GitHub”博客是观察 AI 时代代码托管基础设施压力的一手样本。

反过来，如果你只在 Windows 上工作、或高度依赖某款终端的特定插件生态，Ghostty 目前并不覆盖 Windows，迁移成本要自己掂量。

参考来源

• Ghostty 官网
• Ghostty 文档：About
• Ghostty 文档：Configuration
• Ghostty 下载页（版本 1.3.1）
• Mitchell Hashimoto：Ghostty Is Leaving GitHub（2026-04-28）
• GitHub 仓库 ghostty-org/ghostty
• Koala 项目库条目：Ghostty
• Koala 项目库条目：Ghostty 离开 GitHub