Ghostty 终端核心库 libghostty-vt 发布 1.0 版本

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 等用户现在都拥有一个由 libghostty 驱动的终端。根据 JetBrains 的一份报告，这涉及超过 1250 万活跃用户。

Neovim 有一个已批准的 pull request，用 libghostty-vt 替换 libvterm。除此之外，它还关闭了一个存在 10 年之久的关于调整大小时回滚缓冲区重排的 issue。维护者正在等待一个打上标签的正式发布版本才会合并，以便各发行版能够将该依赖单独打包，而今天的发布应该就能实现这一点。

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 结果，而不是崩溃或未定义行为。我们仅有的几个非不透明结构体都携带自身大小，以便日后追加字段，或者包含保留的填充。枚举在所有编译器上都固定为 int，在 C 标准允许的范围内尽可能如此。

我们的 CI 强制执行 ABI 策略。每次变更都会在 Linux 上使用 libabigail 对照已提交的基线进行检查，在 macOS 和 WebAssembly 上则对照黄金类型清单进行检查。在 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 也不想要，它也可以完全独立构建。3

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

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

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

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