Ghostty 1.4.0：终端大版本发布的正确打开方式 — HN 讨论摘要
原文概要
Ghostty 1.4.0 在 2026 年 10 月 27 日发布。这是 Mitchell Hashimoto 那个以 GPU 加速、纯文本配置著称的终端模拟器的一次大版本：7 个月的工作，172 位贡献者，2889 次提交，官方说发布说明本身是维护者手写的，光是写完这些说明就花了 16 个多小时。
性能是这版的主轴，其中一条来自一个反直觉的发现：在 macOS 上，内核会把每一次从 pty 的读操作限制在约 1 KiB，无论你给的读缓冲多大。Ghostty 以前是读到就处理，于是每 1 KiB 都要付一次单次读的开销，写输出的程序在它解析完之前只能干等着。改成「一个线程抽干 pty、另一个线程解析」之后，macOS 上端到端 I/O 吞吐提升 25% 到 55%（测试环境是 M4 Max，纯文本和 Unicode 文本）。解析器本身的变化更大：纯 ASCII 从 128 MB/s 涨到 725 MB/s，CJK 文本快 3.4 倍，2.6 GB 的 asciinema 真实终端录屏数据集快约 25%。结果是 cat 一个 150 MB 文本文件，在 macOS 上从 1.5 秒降到 566 毫秒。带大滚动缓冲的终端 resize 快约 6 倍；渲染器每帧持有终端锁的时间少 2.7 到 11 倍；OSC 52 剪贴板负载的解析快约 30 倍。
内存是第二条线。Ghostty 现在会透明压缩看不见的滚动缓冲页，典型文本历史下物理内存占用降低 70% 到 90%，压缩只在终端空闲时进行，回滚或搜索时按需解压，因此对 I/O 吞吐没有可测量的影响。压缩腾出的空间让默认滚动缓冲上限从 10 MB 提到 50 MB——按物理内存算，填满新上限通常比旧版的 10 MB 占得更少。macOS 上一个空的终端现在只用约 16 KiB 的页面内存，1.3.1 是 128 KiB；隐藏的标签页会释放 GPU 资源，1 个可见标签 + 20 个隐藏标签时，GPU 内存从约 385 MiB 降到 18 MiB。
图形协议方面，Kitty 图形协议的动画和相对定位被补齐，至此覆盖该规范 100% 的已发布内容，成为 Kitty 之外第一个做到这一点的终端（libghostty 同样）。大图传输改用 SIMD 批量解析，官方基准里快约 16 倍（64 MiB 图像数据，x86_64 Linux）。kitten icat 展示的 GIF 现在能在 Ghostty 里真的动起来，而不是只显示一帧静止画面。
Linux 和 FreeBSD 上换掉了 GtkGLArea：渲染器改用 EGL 在自己的线程上绘制，每帧导出为 DMABUF 交给 GTK 显示，改成三重缓冲，主线程上不再有 OpenGL 调用。最直观的效果是分数缩放下文字不再糊——125% 或 150% 缩放下，文本和框线字符每个渲染像素对应屏幕上一个像素。
这次还实现了 Kitty 剪贴板协议（OSC 5522）。原先的 OSC 52 只能读写纯文本，新协议让终端里跑的程序可以读写图片或 HTML 等任意剪贴板数据，还能选择剪贴板上的格式，粘贴时也能通过 mode 5522 告知程序「这次粘贴里有哪些格式」，这样程序就能接住粘贴进来的图片。读取仍然要用户授权，提示里会预览剪贴板内容（包括图片）；新增的 clipboard-write-limit-bytes 默认限制单次写入 64 MiB。
安全部分一次性列出 10 个 GHSA 公告。比较扎眼的几个：粘贴保护没把回车当成行尾，导致在不支持 bracketed paste 的程序里，粘贴可以不经确认就执行命令；恶意 Kitty 图形命令可以崩溃或卡死 Ghostty、强制巨额分配，极端情况下能读写临时目录之外的文件；tmux control mode 可以被恶意终端输出打到崩溃整个 Ghostty（影响 1.3.0 和 1.3.1）；一个精心构造的目录名能让 zsh 集成发送任意转义序列，包括用 OSC 52 悄悄替换剪贴板；macOS 上 cmd+点击精心构造的 OSC 8 链接可以打开不安全的目标并导致任意命令执行。
新命令 ghostty +ssh 是一个 drop-in 的 ssh 包装：连上去之前先在远端装好 Ghostty 的 terminfo，好让远端能用正确的 xterm-ghostty TERM 值，并转发 COLORTERM、TERM_PROGRAM、TERM_PROGRAM_VERSION；装不上（比如远端没有 tic）就退回 TERM=xterm-256color。此前这套逻辑在 bash、zsh、fish、elvish、Nushell 的每份集成脚本里各有一份拷贝，现在统一走 +ssh。terminfo 缓存按主机和端口分别记账，+ssh-cache 改成位置参数并新增 --prune=30d。
兼容性上有个不太受欢迎的消息：GTK 端最低要求升到 GTK 4.18 + libadwaita 1.7，Ubuntu 24.04 LTS 不满足。macOS 侧反而保住了 macOS 13 Ventura，但官方说明未来版本会放弃。
作者本人在评论里补了一条更重要的信息：libghostty 才是这个项目的真正目的。它现在的核心覆盖率接近 Ghostty 的 100%，在 CI 里构建并测试 Apple 全平台、Windows（MSVC 和 GNU）、Linux、FreeBSD、Android、WebAssembly 以及 freestanding（直接在裸硬件上跑、没有操作系统）；几乎所有流行语言都有绑定；一个空终端的内存占用降了 90%；作者在 4 核 8 GB 的 Linux 服务器上验证过 10000 个活跃终端。它驱动着所有 JetBrains IDE 的终端，超过 1250 万活跃用户。Neovim 那边正在讨论用 libghostty 替换终端核心（PR #39773，工作仍在进行）；emacs 侧有 Ghostel；Antithesis 用它的速度去 fuzz 热门终端程序，直接催生了发往 tmux、btop、各类 shell 和其他终端模拟器的数百个上游修复。作者宣布打算在接下来几个月给 libghostty 打 1.0 标签，并在那时声明 ABI 稳定。这条 HN 帖子拿到 410 分、130 条评论。
讨论焦点
一、Konsole 到底行不行：一场老终端与新终端的站队
帖子的第一条评论就是站队，而且站的是一个在终端模拟器圈子里最不受待见的对手：
“I still don’t understand the point of Ghostty, Kitty, Wezterm…” — cassianoleal [c:50262524] （译文：我还是不理解 Ghostty、Kitty、WezTerm 这些东西存在的意义……）
理由是 Konsole 更快：
“Konsole is way faster than any of those on my computer and it has all the usual suspects I’d expect from a modern terminal emulator.” — cassianoleal [c:50262524] （译文：在我机器上，Konsole 比它们任何一个都快，而且一个现代终端模拟器该有的东西它都有。）
他特意强调自己不是来贬低的：
“To be clear, I’m not attempting to be dismissive. I really want to understand what it is that they bring.” — cassianoleal [c:50262524] （译文：说清楚，我不是在试图贬低谁。我是真的想理解它们带来了什么。）
但反驳几乎是即时的，而且给的是实测数据：
“At least in my computers (with NVIDIA GPUs and Gentoo Linux), kitty was many times faster than Konsole and Ghostty even faster.” — adrian_b [c:50263234] （译文：至少在我的机器上（NVIDIA GPU、Gentoo Linux），kitty 比 Konsole 快很多倍，Ghostty 还要更快。）
acedTrex 一句话把「速度」这条线挑明了：
“The acceleration is the primary point.” — acedTrex [c:50263705] （译文：GPU 加速才是关键。）
而从应用开发者角度看，Konsole 的问题不在速度，在默认行为。reissbaker 列了两条他打包 CLI 程序时踩过的坑：
“By default, Konsole disables OSC8 link support. Users can enable it manually, but you need to ship fallbacks by default since otherwise the default users will have a broken experience. Ghostty, Kitty, WezTerm, etc all ship working OSC8 support out of the box.” — reissbaker [c:50262841] （译文：Konsole 默认关闭 OSC 8 链接支持。用户可以手动打开，但你必须在默认配置里自带降级方案，否则默认用户会拿到一个坏掉的体验。Ghostty、Kitty、WezTerm 这些都默认开着能用的 OSC 8 支持。）
“The worst by far is Apple Terminal, truly the IE6 of terminal emulators.” — reissbaker [c:50262841] （译文：最糟的无疑是 Apple Terminal，它就是终端模拟器里的 IE6。）
这场站队的另一端也有人给出更软的答案——跨平台本身就是理由：
“I use Linux at home and Mac at work. I use Ghostty simply to have the same terminal on both systems.” — paride5745 [c:50262660] （译文：我在家用 Linux、在公司用 Mac。我用 Ghostty 只是想在两个系统上用同一个终端。）
二、libghostty 才是主角，作者自己下场解释
真正把讨论点燃的是作者 Mitchell Hashimoto 的那条长评。他先说了为什么当初要开这个项目：
“It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!).” — mitchellh [c:50262760] （译文：它一直是也永远是 Ghostty 项目的真正目的（我第一次公开谈 Ghostty 时就这么说过！）。）
他随即甩出一串清单，其中最有分量的几条是：
“Libghostty powers all JetBrains IDE terminals, over 12.5 million active users.” — mitchellh [c:50262760] （译文：libghostty 驱动着所有 JetBrains IDE 的终端，超过 1250 万活跃用户。）
“Libghostty’s speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators.” — mitchellh [c:50262760] （译文：Antithesis 用 libghostty 的速度去 fuzz 热门终端程序，这直接催生了发往 tmux、btop、各类 shell 和其他终端模拟器的数百个上游修复。）
“I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!” — mitchellh [c:50262760] （译文：我打算在接下来几个月给 libghostty 打上 1.0 标签，并在那时宣布 ABI 稳定！）
一个尖锐的读者当场指出——这不是 changelog，是客户名单：
“I’m super excited for you and this, but this is mostly a highlight list of who is using your library. I was kind of excited to read about the actual changes to the library but I suppose I can go read the changelog on my own.” — TrueDuality [c:50263047] （译文：我为你和这件事感到非常兴奋，但这份东西基本上是一份「谁在用你的库」的清单。我本来挺期待看看这个库本身到底改了什么，不过我大概可以自己去读 changelog。）
生态里的人给出了另一层解读。sigbottle 认为这是一个行业层面的转向：
“The terminal ecosystem needs to change, and these terminals support a lot of cool features. Ghostty’s pure reusable terminal state machine being a source of truth, Kitty graphics, Wezterm and its mux domains & lua config, lots of cool ideas there.” — sigbottle [c:50262580] （译文：终端生态需要改变，而这些终端支持很多很酷的特性。Ghostty 把纯粹可复用的终端状态机当作唯一事实来源，Kitty 的图形协议，WezTerm 的 mux 域和 Lua 配置，好想法太多了。）
真正做过这件事的人给了最有分量的一句。来自 Neovim core 的 ashkankiani 说，他和作者六年前就想到过同一件事，只是当时没做：
“But that was 6/7 years ago (2019) and a lot of stuff happened in that interim unrelated to engineering that demotivated me from pursuing it.” — ashkankiani [c:50265100] （译文：但那是六七年之前（2019 年）的事了，这中间发生了一大堆跟工程无关的事，让我没了继续做的动力。）
“Thanks for the good work to raise all boats :)” — ashkankiani [c:50265100] （译文：感谢你做的这件拉高所有人水位的事。）
连 KDE 项目的人都在往 libghostty 上靠：
“I’m from the KDE project, and have been working on a new frontend built on libghostty-vt to hopefully one day ease our maintenance burden.” — sho_hn [c:50264002] （译文：我来自 KDE 项目，正在用 libghostty-vt 做一个新的前端，希望有一天能减轻我们的维护负担。）
三、没有 GUI 设置界面，是 feature 还是 bug
Ghostty 最被诟病也最被坚持的一点，是它不提供图形化设置界面。这条争论在评论里几乎和性能问题一样长，而且分成泾渭分明的两派。
反对派最直白的表述：
“Yeah, except the default config file doesn’t EXIST and there is nothing but the reference docs to tell you what the hell you’re supposed to put in there. What am I supposed to do, guess? Is it
font=orfont-familyorfont-name? That’s fucking terrible.” — wpm [c:50264158] （译文：是啊，除了默认配置文件根本不存在、除了参考文档之外没有任何东西告诉你到底该往里填什么。我该怎么办，猜吗？是font=还是font-family还是font-name？这太他妈离谱了。）
他其实试过然后退回去了：
“I’d love to, I switched back to iTerm after not really feeling any big difference in my uses cases, but also hating the crappy plain text with no defaults listed config that required me to use a goddamn web app to comfortably learn and fill out.” — wpm [c:50262815] （译文：我很想用，但我最后换回了 iTerm——在我的使用场景里没感到什么明显差别，同时受够了那份糟糕的纯文本配置：没有列出默认值，还得靠一个他妈的网页应用才能舒服地学习和填写。）
支持派则认为这是设计而不是缺陷：
“I feel like good tools should be invisible and Ghostty’s lack of fully fledged Settings app is a feature, not a bug.” — paaloeye [c:50263204] （译文：我觉得好工具应该隐形，而 Ghostty 没有一个完整的设置应用，这是特性不是 bug。）
diath 给了第三个角度——选终端本来就有三类不同的理由：
“1) Personal preferences: different terminals come with different defaults, some people do not want to tinker with the settings, so they just stick with whatever immediately clicks.” — diath [c:50262965] （译文：1）个人偏好：不同终端有各自的默认配置，有些人不想去折腾设置，于是就用手感最顺手的那个。）
“2) Technical curiosity: some people probably started their own terminal project just for the fuck of having made their own - and they eventually gained a userbase.” — diath [c:50262965] （译文：2）技术好奇心：有些人做自己的终端项目，纯粹就是为了「我自己写了一个」这件事本身——然后他们慢慢攒出了用户群。）
最后一派则指出，有些人的前提就不同：
“Funny, I won’t use a term emulator unless it has a good GUI config. Even SGI and Windows Command prompt had them in the 90s.” — mixmastamyk [c:50263387] （译文：有意思，没有像样的图形界面配置我就不肯用终端模拟器。90 年代的 SGI 和 Windows 命令提示符都有那玩意儿。）
四、terminfo 与 SSH：老毛病的新包装
1.4.0 主推的 ghostty +ssh 是这次最实用的改动，但也正好踩中了终端模拟器最经典的那个坑：本地 TERM 值在远端没人认识。
症状由一条评论精确描述：
“Very likely due to ghostty setting TERM to xterm-ghostty and your destination not recognizing it.” — awkwardleon [c:50263684] （译文：很可能是因为 Ghostty 把
TERM设成了xterm-ghostty，而你的目标机器不认识它。）
最惨烈的案例来自 Ubuntu：
“Yea unfortunately eg Ubuntu’s bashrc has a script which will make it drop colors regardless of the presence of ghostty’s terminfo. Its
screenwill also fail, so e.g. it will refuse to upgrade to a new distro release.” — iknowstuff [c:50265041] （译文：是啊，很遗憾——比如 Ubuntu 的 bashrc 里有个脚本，不管有没有 Ghostty 的 terminfo 都会把颜色丢掉。它的screen也会失败，比如导致它拒绝升级到新的发行版。）
“Lots of jank due to this custom terminfo.” — iknowstuff [c:50265041] （译文：因为这个自定义 terminfo，乱七八糟的破事一大堆。）
连启动速度都被波及：
“The other day I was able to click on Ghostty, then open Gnome Terminal, type a command and run it before Ghostty had finished loading.” — n6242 [c:50263635] （译文：前几天我点了 Ghostty，然后打开 GNOME Terminal、敲一条命令并执行，这期间 Ghostty 还没加载完。）
而「在别人机器上装东西」这件事本身，触及了一条很多人默认接受、也有人坚决反对的边界：
“It’s rude to install a terminfo on a remote machine (which you may not be the owner of). It’s a preposterous for a terminal emulator to install things on a remote machine just to make it work.” — kccqzy [c:50263836] （译文：在远端机器（可能你都不是所有者）上装 terminfo 是很没礼貌的。终端模拟器为了让自己能工作就往远端机器上装东西，这荒谬透顶。）
adrian_b 把这条边界讲清楚了：
“Otherwise, there is no need to install anything, you should just set the environment variable TERM in the remote computer to one of the xterm variants and then modern terminal emulators like kitty or ghostty will still work fine, but of course only as long as you use the xterm-compatible subset of their features.” — adrian_b [c:50264308] （译文：否则其实什么都不用装，你只要把远端机器上的
TERM环境变量设成某个 xterm 变体，现代终端模拟器比如 kitty 或 ghostty 就照样能正常工作——当然，前提是你只用 xterm 兼容的那部分特性。）
最省事的解法通常是在 SSH 配置里覆盖环境变量：
“You can also just add this to your SSH config to get the typical functionality working:” — seanw444 [c:50264140] （译文：你也可以在 SSH 配置里加上这个，让常规功能正常工作：）
对 +ssh 本身有期待的人也有。Hitech-Redneck 说 SSH 时的怪毛病一直让他没法从 iTerm2 迁走：
“I loved Ghostty for thr first month I tried it, but got some strange behavior when SSHing into some machines. Sounds like this release may address that.” — Hitech-Redneck [c:50262764] （译文：我试用 Ghostty 的第一个月很喜欢它，但在 SSH 进某些机器时遇到了一些奇怪行为。听起来这次的发布正好解决这个。）
五、十个安全公告：终端是个攻击面
一次发 10 个 GHSA 公告本身就是新闻。有人从「终端不该那么复杂」的角度切入：
“There should not be any more complexity in a terminal emulator that will just lead attackers to craft RCEs exploits to your terminal to steal your secrets on your computer just because “Its cool” and has hundreds of escape codes.” — rvz [c:50263256] （译文：终端模拟器里不该再有更多复杂度，因为这些复杂度只会让攻击者有动机去构造 RCE 漏洞来攻击你的终端、从你电脑上偷走秘密——只因为「这很酷」，而它有几百个转义序列。）
把十份公告串起来看，攻击面基本都落在三类东西上：转义序列、图形协议、链接。链接那一类尤其能说明问题——macOS 上 cmd+点击一个 OSC 8 链接就可能执行任意命令，而 Konsole 干脆默认把 OSC 8 关掉。有人认为这才是正确的默认值：
“That is, in my opinion, the correct default.” — hnlmorg [c:50263746] （译文：在我看来，那才是正确的默认值。）
也有人认为默认值应该反过来——不确认就不打开：
“I believe that the default behavior should be to never open a link without a confirmation from the user that this may be done.” — adrian_b [c:50264031] （译文：我认为默认行为应该是：在没有用户确认的情况下，绝不打开链接。）
六、图形支持与 AI 味：Kitty 协议和 Claude Code
这次补齐 Kitty 图形协议动画，最实际的一个用途居然和 AI 编码 agent 有关。Lerc 做了一个 Claude Code skill：
“I made a Claude code skill telling it to put a little image in the corner of the console when it does a render to see how something looks.” — Lerc [c:50262783] （译文：我做了一个 Claude Code 的 skill，让它在每次渲染时往控制台角落放一张小图片，好让我看看效果。）
the_mitsuhiko 从另一个方向确认了这件事的价值：
“I’m not sure why you want shaders, but if you use a coding agent in the terminal you definitely want image support. Otherwise it’s very hard to see what the agent is seeing.” — the_mitsuhiko [c:50263084] （译文：我不确定你为什么想要着色器，但如果你在终端里用编码 agent，你一定需要图像支持。否则你很难看出 agent 在看什么。）
对性能的评价则直接来自日常使用：
“MacOS terminal had issues keeping up with Claude Code. It would frequently be super slow rendering the text output or sometimes just stop altogether.” — alemanek [c:50264813] （译文：macOS 自带的终端跟不上 Claude Code，渲染文本输出时经常慢得要命，有时干脆卡住。）
另一派担心的是反向的：终端里别塞 AI。lifeisloving 的担心很具体：
“I really hope they dont start adding llm junk to ghostty.” — lifeisloving [c:50262859] （译文：我真心希望他们别开始往 Ghostty 里塞 LLM 垃圾。）
于是有人替作者辩护，说他在 AI 这件事上的位置恰恰是「温和派」：
“For me, mitchellh defines the moderate position on agents in coding, I mean that seriously: not occupies it, defines it.” — samatman [c:50265022] （译文：对我来说，mitchellh 界定了在编码 agent 这件事上的温和立场，我是认真这么说的：他不是占据了这个立场，而是定义了这个立场。）
“He’s better known for a mitigation to LLM downsides (vouch) than for making conspicuous use of them, and insists on human-only prose in issues, PRs and ‘real’ documentation (which I firmly agree with btw).” — samatman [c:50265022] （译文：比起显摆地使用 LLM，他更出名的是为 LLM 的副作用做了缓解（vouch），而且坚持在 issue、PR 和「真正的」文档里只用人写的散文（这一点我完全同意）。）
评论区里还有一条更实用的动机——崩一个不要紧：
“The point for me is each one can have ten or so claudes, so any one crashing doesn’t take down all the claudes … and I don’t have to learn tmux.” — bombcar [c:50262880] （译文：对我来说重点是每个窗口可以开十个左右的 Claude，这样崩一个不会把所有 Claude 一起带走……而且我不用去学 tmux。）
七、库能走多远：freestanding、Neovim，以及下一个竞争者
评论区对 libghostty 的实际野心问出了几个很实在的问题。最直接的是 freestanding 到底给谁用：
“That’s really cool, but I’m drawing a blank; what’s it used for? Embedded terminal something?” — yjftsjthsd-h [c:50263213] （译文：这确实很酷，但我完全想不出它是干嘛用的？嵌入式终端之类的吗？）
Imustaskforhelp 认真答了一遍，并且给出了一个很实际的场景：
“But aside from the fun little demo, what are the real use cases that we can think of as well.” — Imustaskforhelp [c:50263607] （译文：不过除了那个好玩的小 demo，我们还能想到哪些真正的使用场景呢。）
“1. SSH’ing into a terminal (VPS) or being able to view what the AI agents are doing on that VPS and controlling them very thinly in your pocket.” — Imustaskforhelp [c:50263607] （译文：1）SSH 进一台终端（VPS），或者能在口袋里远程查看那台 VPS 上的 AI agent 在干什么、并做非常轻量的控制。）
至于「下一个竞争者」，评论里已经出现了另一个名字——Superlogical 的 Rex。hmokiguess 已经换过去了：
“I have replaced Ghostty with Rex from Superlogical, it’s great and I really like the iOS app too.” — hmokiguess [c:50262768] （译文：我已经把 Ghostty 换成了 Superlogical 的 Rex，它很棒，我也很喜欢它的 iOS 应用。）
selectnull 说得很直接：
“Rex will allow me to use my old workflow again.” — selectnull [c:50262884] （译文：Rex 能让我用回以前的 workflows。）
而在作者那边，评论里最扎眼的待办不是功能，而是这个项目要搬到哪儿去：deaux 直接问了那个所有人都在想的问题：
“I’m sure mitchellh will check out this comment section at some point - any updates on the move away from Github? I don’t really see anything that’s changed, but maybe it’s behind the scenes. I was pretty excited on your initial post about it but it’s been a while.” — deaux [c:50262740] （译文：我相信 mitchellh 迟早会看到这个评论区的——从 GitHub 迁出去这件事有进展吗？我没看出有什么变化，也许在幕后。我当初看到他宣布这件事时挺兴奋，但已经过去一阵子了。）
典型观点一览
| 立场 | 用户 | 一句话 |
|---|---|---|
| 不理解这些终端存在的意义 | cassianoleal | Konsole 更快，还什么都有 |
| 不是来贬低的，是真想知道 | cassianoleal | 我真想知道你们带来了什么 |
| kitty 快过 Konsole，Ghostty 更快 | adrian_b | NVIDIA + Gentoo 实测 |
| GPU 加速才是关键 | acedTrex | 加速是主要目的 |
| Konsole 默认关掉 OSC 8 | reissbaker | 默认用户会拿到坏体验 |
| Apple Terminal 是终端里的 IE6 | reissbaker | 最糟的那个 |
| 跨平台才是选它的理由 | paride5745 | 家里 Linux 公司 Mac |
| libghostty 才是项目的真正目的 | mitchellh | 从第一次演讲就这么说过 |
| 驱动 JetBrains 全部终端 | mitchellh | 1250 万活跃用户 |
| 被用来 fuzz 终端程序 | mitchellh | 催生数百个上游修复 |
| 几个月内打 1.0 并稳定 ABI | mitchellh | 库路线的时间表 |
| 这是客户名单不是 changelog | TrueDuality | 库本身的改动呢 |
| 终端生态需要改变 | sigbottle | 状态机作为唯一事实来源 |
| 早就该有这样一个库 | ashkankiani | 六年前在 Neovim core 有同样想法 |
| KDE 也在往 libghostty 上靠 | sho_hn | 想减轻维护负担 |
| 默认配置文件根本不存在 | wpm | 我该填 font= 还是别的 |
| 用过还是换回 iTerm | wpm | 没有默认值，只能靠网页应用 |
| 没有 GUI 是特性不是 bug | paaloeye | 好工具应该隐形 |
| 选终端有三类理由 | diath | 偏好、好奇心、功能集 |
| 没有 GUI 就不用的终端党 | mixmastamyk | 90 年代都有图形界面 |
| 远端不认 xterm-ghostty | awkwardleon | 症状与病因 |
| Ubuntu bashrc 遇到 terminfo 就掉色 | iknowstuff | screen 也坏，连升级都受阻 |
| 在别人机器上装 terminfo 很没礼貌 | kccqzy | 终端不该往远端装东西 |
| 换个 xterm 变体就够了 | adrian_b | 只是要用 xterm 兼容子集 |
| SSH 配置里覆盖 TERM 即可 | seanw444 | 最省事的解法 |
| SSH 怪毛病让我留在 iTerm2 | Hitech-Redneck | 这版可能修好 |
| 终端的复杂度只会招来 RCE | rvz | 就因为「这很酷」 |
| 关掉 OSC 8 才是正确默认 | hnlmorg | 同意 Konsole 那一派 |
| 打开链接必须用户确认 | adrian_b | 默认不该直接打开 |
| 用 Claude Code 就需要图像支持 | the_mitsuhiko | 否则看不出 agent 在看什么 |
| 给 agent 渲染角落插张图 | Lerc | 写了个 Claude Code skill |
| macOS 终端跟不上 Claude Code | alemanek | 渲染慢，有时直接卡住 |
| 别往 Ghostty 里塞 LLM 垃圾 | lifeisloving | 现在这样就挺好 |
| 作者是编码 agent 的温和派 | samatman | 他定义了那个立场 |
| 更出名的是给 LLM 副作用做缓解 | samatman | 坚持文档只用人写的文字 |
| 一个窗口开十个 Claude | bombcar | 崩一个不带走全部，还不用学 tmux |
| freestanding 到底给谁用 | yjftsjthsd-h | 我想不出是干嘛的 |
| 口袋里的 VPS agent 控制台 | Imustaskforhelp | 最现实的场景 |
| 已经换成 Superlogical 的 Rex | hmokiguess | iOS 应用也不错 |
| Rex 能让我用回旧 workflow | selectnull | 从 WezTerm 迁过来的原因 |
| GitHub 迁移到底有没有进展 | deaux | 我挺期待那件事的 |
总体情绪
Ghostty 1.4.0 本身没什么可争议的。7 个月、172 人、2889 次提交，性能数据一个比一个硬：ASCII 解析 5.7 倍、滚动缓冲物理内存省 70% 到 90%、隐藏标签页把 GPU 内存从 385 MiB 压到 18 MiB、Kitty 图形协议做到 100% 覆盖。这是一次教科书式的、把「终端到底有多快」和「终端到底有多少内存」一次性解决掉的发布。
但评论区的注意力几乎没落在这些数字上。它落在三个更世俗的问题上：Konsole 到底行不行、终端该不该有图形界面、以及 SSH 到不认识 xterm-ghostty 的机器上该怎么办。这三件事的共同点是——它们都不是「选哪个」，而是「凭什么」。Ghostty 把「快」做到了极致，同时也把「什么都没有」推到了极致：一个不存在的默认配置文件、一个远端装不上就退化成 xterm-256color 的 terminfo 方案、一个连 GUI 设置都没有的极简哲学。支持派说这就是隐形好工具该有的样子，反对派说这是把用户的痛苦当特性。10 个安全公告更把这件事推到了极端——你享受的每一个「更聪明」都对应着一条新的攻击路径。
而作者自己已经把答案写在了评论区里：他花一整条长评讲的不是 Ghostty 这个应用，是 libghostty 这个库——一个要被嵌进 JetBrains、Neovim、emacs、KDE 和各种「agentic 终端」里的可复用内核，并且要宣布 ABI 稳定。发布说明里那场 5.7 倍的性能优化，检验的是 GPU 加速的渲染管线；而 libghostty 检验的是同一套终端逻辑被嵌进别人的产品之后会不会先崩掉。前者是这次发布的主线，后者才是作者在写的下一个五年。
引用帖子
| # | 标题 | URL |
|---|---|---|
| 1 | Ghostty 1.4.0 Release Notes（官方） | https://ghostty.org/docs/install/release-notes/1-4-0 |
| 2 | HN 讨论 | https://news.ycombinator.com/item?id=50261998 |
| 3 | libghostty 项目主页 | https://libghostty.tip.ghostty.org/ |
| 4 | Neovim：改用 libghostty 作为终端核心（PR #39773） | https://github.com/neovim/neovim/pull/39773 |
| 5 | JetBrains 终端改用 Ghostty（作者评论中引用的公告） | https://blog.jetbrains.com/platform/2026/10/jetbrains-terminal-now-uses-ghostty/ |
| 6 | Ghostel：基于 libghostty 的 emacs 终端 | https://github.com/dakra/ghostel |
| 7 | Ghostty SSH 集成文档 | https://ghostty.org/docs/features/ssh |
| 8 | Ghostty 安全公告列表（GHSA） | https://github.com/ghostty-org/ghostty/security/advisories |
免责声明
本摘要由 AI 模型辅助生成：minimax-cn-coding-plan/MiniMax-M3