你用的终端可能已经是它：libghostty 1.0 悄悄进了 JetBrains

Ghostty 作者 Mitchell Hashimoto 11 月 6 日发了篇博文：Ghostty 背后的终端模拟库 libghostty 出了 1.0——一个可移植、高性能的 C 语言终端模拟库，直接从 Ghostty 核心抽出来。1.0 的含义很明确：库本身与 C ABI 都已稳定。HN 上 57 分（2026-11-07 快照）。

这篇值得单独写的不是"又一个终端发布"，而是一个 quietly 发生的事实：你用的终端可能已经是它了。

Ghostty 仓库

谁在用它（博文原文，作者口径）

JetBrains：IntelliJ、PyCharm、GoLand 等 IDE 的内置终端已跑在 libghostty 上，据 JetBrains 的报告，全部用户都已用上、超 1250 万活跃用户；
Neovim：已有获批的 PR，用 libghostty-vt 替换 libvterm，顺带关掉一个 10 年未决的"调整大小时重排 scrollback"issue——在等一个正式 tag 发布后合并，方便发行版单独打包；
KDE：开发者在试验基于它的 Konsole 替代品；
Vercel Turborepo 用它在 TUI 里渲染任务输出；devenv 用它驱动 shell；Antithesis 用它 fuzz TUI 程序、在 btop 等工具里找到过真实 bug；OrbStack 等商业产品内嵌它；
herdr、cmux 等一批新终端与"agentic"编码工具直接基于它构建，不再自己写模拟器。

规模数字：社区绑定覆盖 Rust、Go、JavaScript、Swift、Python、.NET、Elixir、Dart、Java 等语言，awesome-libghostty 收录超 100 个项目。作者的总结很直白：今天用 libghostty 驱动的终端的人，比用 Ghostty 本体的人多得多。

技术上做对了什么（作者口径）

HN 上关于 libghostty 的讨论

MIT 许可证；除 libc 外零依赖，也能完全 freestanding 编译；仅有的依赖是 simdutf、Google Highway（SIMD）、一张紧凑的 Unicode 字形表和 Wuffs（Kitty 图形协议解码），无任何 copyleft 代码。API 设计上全部用不透明句柄、枚举键控的 getter/setter，加新值不新增符号；CI 用 libabigail 对照基线强制执行 ABI 策略，ELF 平台全部导出符号带版本。平台覆盖 Linux（glibc/musl）、macOS 13+、iOS 13+、FreeBSD、Windows、Android、WebAssembly；不创建线程、分配器可自定义。

性能上作者给了一组自述实测：4 核 8GB 服务器上跑 1 万个活跃终端（每个带 live shell 输出），bash 自身占的内存比 libghostty-vt 还多；用它约 1500 行 C 就能做出一个功能与性能超过 2025 年绝大多数终端的终端。

发布形态也是按"库"的标准来的：独立于 Ghostty 应用的发布周期，每版发带签名的源码 tarball 与依赖 tarball（Zig 缓存布局、可离线构建），装 shared/static 库、SONAME、头文件、pkg-config 与 CMake 配置，打包文档见 PACKAGING-LIBGHOSTTY.md。

判断：最难啃的脏活，终于有人做成了库

对开发者，这篇的实际意义一句话：终端模拟这个最难啃的脏活，终于有人把它做成了稳定、可复用的库——以前每个终端、每个 TUI 工具都要自己啃转义序列和回流逻辑，现在 1500 行 C 就能搭一个。三点校准：① 1.0 稳定的是库与 ABI，不是"功能全了"，作者明确说后续重心是补齐终端协议、保持稳定；② Neovim 的替换 PR 还没合并，在等正式 tag；③ 它是"库"不是"应用"，别当成开箱即用的终端。另注意别和 Ghostty 应用 1.4（2026 年 10 月 27 日发布）混为一谈——那是应用的版本，这是库的 1.0。