Ghostty 提取的终端模拟库 libghostty-vt 发布 1.0，C ABI 稳定

libghostty-vt 1.0 正式发布。libghostty 是一个可移植、高性能的终端模拟 C 库，直接从 Ghostty 的核心中提取而来。1.0 版本的发布意味着库本身和 C ABI 现在都已稳定。

一年多以前，我写过 libghostty 即将到来。当时，Zig 模块刚刚合并，C API 还不存在，除了 Ghostty 之外没有任何使用方。今天，C API 已经是一个完整的终端模拟器，在数百个产品（既有免费也有商业）中为数百万人生产运行，并且拥有真正强制执行、落到实处的 ABI 稳定性策略。这篇文章讲的是我们如何走到这一步，以及 1.0 究竟意味着什么。1

自 2022 年启动 Ghostty 项目以来，我被问得最多的问题就是"为什么？"。我已经在 libghostty 即将到来那篇文章里回答过了，感兴趣的话可以去读。今天，我更想通过展示 libghostty 已经产生的广泛行业影响来回答这个问题。我相信这有力地证明了它存在的价值。

一年前，我拿 JetBrains IDE 中的终端模拟器 JediTerm 的一个 bug 作为例子，说明终端模拟为什么很难做对。一年后，JetBrains IDE 中的终端已经运行在 libghostty 之上。每一位 IntelliJ、PyCharm、GoLand 等 IDE 的用户，现在用的都是 libghostty 驱动的终端。根据 JetBrains 的一份报告，这涉及超过 1250 万活跃用户。

Neovim 有一个已批准的 pull request，用 libghostty-vt 替换 libvterm。这解决了诸多问题，其中包括一个存在了 10 年之久的 resize 时回滚缓冲区重排（reflow）问题。维护者正在等待一个带 tag 的正式发布版本再合并，以便各发行版可以单独打包这个依赖，而今天的发布应该能满足这一条件。

KDE 开发者正在试验基于它构建的 Konsole 替代品。Vercel 的 Turborepo 用它在其 TUI 中渲染任务输出。devenv 用它来驱动 shell。Antithesis 用它来对 TUI 程序做模糊测试，并在 btop 等程序中发现了真实 bug。Ghostel 把它带到了 Emacs。ghostty-web 是它的 WASM 构建，提供与 Xterm.js 兼容的 API。OrbStack 等商业产品将其嵌入。还有一大批新终端和"智能体"（agentic）编程工具，比如 herdr 和 cmux，选择基于它构建，而不是再写一个终端模拟器。

社区为 Rust、Go、JavaScript、Swift、Python、.NET、Elixir、Dart、Java 等语言提供了绑定，awesome-libghostty 列表追踪了超过一百个项目。

今天使用 libghostty 驱动终端的人，远远多于使用 Ghostty 应用本身的人，差距极大。而 libghostty 产生的影响，也远远超出了"只是一个"终端模拟器的范畴。2

1.0 意味着 libghostty-vt 遵循语义化版本，并有严格的 ABI 兼容性承诺，从而让各发行版和操作系统的打包者可以放心打包 libghostty-vt，程序开发者也可以放心动态链接它。

除了提供有用的功能，我认为一个高质量、持久的 C 库的标志就是 ABI 稳定性。因此从一开始，我就从我喜欢的 C 库中汲取灵感，把 API 设计成拥有强大、稳定的 ABI，同时允许未来添加新内容。

每个对象都是不透明句柄。你可能读写的数百个值，都通过一小套以枚举为键的 getter 和 setter 来访问，这样我们就能轻松添加新值，而无需引入新的符号。用较新头文件编译的程序链接到较旧版本的 libghostty 时，会得到 GHOSTTY_UNSUPPORTED 结果，而不是崩溃或未定义行为。我们为数不多的非不透明结构体都携带自身大小，以便日后追加字段，或者包含预留的填充。枚举在 C 标准允许的范围内，在所有编译器上都固定为 int。

我们的 CI 强制执行 ABI 策略。每次改动都会在 Linux 上用 libabigail 对照已提交的基线进行检查，在 macOS 和 WebAssembly 上则对照黄金类型清单（golden type manifest）检查。在 ELF 平台上，每个导出的符号还都做了版本化，因此动态加载器会按名称拒绝加载不匹配的库，而不是在之后以某种难以解释的方式失败。

除了 ABI 稳定性，1.0 版本还带来了完善的构建工具、tarball、依赖许可清单、文档等，使每个主流操作系统和发行版都能通过标准的官方工具打包 libghostty-vt。

Libghostty 有自己独立的发布周期，与 Ghostty 应用分开。它也有自己的 tarball，只包含 libghostty 所需的文件和依赖，因此体积更小，许可验证和兼容性检查也更简单。

每个版本都会发布一个签名的源码 tarball，以及一个配套的依赖 tarball，其中包含 Zig 自身缓存布局下的所有 Zig 包，这样发行版就可以完全离线构建该库。构建过程会安装共享库和静态库，带有正确的 SONAME、头文件、pkg-config 文件和 CMake 包配置，并支持 --prefix、DESTDIR 和 lib64。调试信息默认保留，以便发行版可以单独剥离。所有这些都记录在随 tarball 一起发布的 PACKAGING-LIBGHOSTTY.md 中。

libghostty-vt 采用 MIT 许可。运行时它只需要 libc，如果你连 libc 都不想要，它也可以完全脱离环境（freestanding）构建。3

这个库编译时只依赖少量宽松许可的组件：用于 SIMD 的 simdutf 和 Google Highway、用于字素（grapheme）数据的紧凑 Unicode 表，以及用于 Kitty 图形协议中图像解码的 Wuffs。simdutf 和 Highway 都在不依赖 libc++ 的情况下构建，因此没有 C++ 标准库依赖。

依赖树中没有任何 copyleft 代码。每个依赖都列在机器可读的清单中，包含版本、SPDX 许可证和哈希，专门是为了让发行版更容易填写其捆绑库元数据。如果某个发行版更愿意动态链接系统的 simdutf 或 Highway，也有相应的构建开关。

libghostty-vt 高度可移植。下表列出了所有平台

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）