2026 年 10 月 27 日，开源 GPU 加速终端模拟器 Ghostty 正式发布 1.4.0 版本，汇集了 172 名贡献者在 7 个月内的 2,889 次代码提交，连发行说明都由维护者耗时 16 小时以上纯手工撰写。这次更新把压缩回滚缓冲区的物理内存占用砍掉了 70% 至 90%，将大型图像解析速度提升了 约 16 倍，并成为除 Kitty 本身之外首个 100% 完整实现 Kitty 图形协议的终端；同时它集中披露并修复了 10 个安全漏洞，旧版本用户哪怕只是在终端里查看一段不可信文本或切入一个克隆下来的代码仓库，都可能触发崩溃或剪贴板劫持。
Ghostty 1.4.0 并非一次常规的功能堆砌，而是一场针对历史性能短板的自我救赎，更是现代终端模拟器加速“浏览器化”后的安全集中排雷。在 Kitty、Alacritty、WezTerm 和 Ghostty 四强争霸的赛道里，它选择了一条最重的全功能原生路线，也因此撞上了最复杂的底层解析风险。
甩开 WezTerm 补齐图形短板与内存救赎
在终端内直接预览高帧率图像和构建富媒体 TUI（终端用户界面）应用，Kitty 图形协议早已是事实标准，但各家终端的支持度长期处于分裂状态。Alacritty 为了极简与低内存完全拒绝支持该协议；WezTerm 虽然支持静态图形，但对动画协议的支持并不完整，至今仍会忽略动画控制命令；Ghostty 1.4.0 则彻底补齐了帧传输、合成、播放控制以及相对位置放置（Relative Placements），让子图像可以跟随父图像同步移动，并借助 SIMD 批量解析将 64 MiB 图像数据的解析速度提升了 约 16 倍。对于 Neovim 插件或终端文件管理器 Yazi 的开发者而言，市场上终于有了第二个能完整跑通 Kitty 动画规范的终端底座。
比图形能力更迫切的是内存与吞吐量的翻身仗。官方公布的数据极具冲击力：通过在空闲时透明压缩不可见的回滚历史，Ghostty 1.4.0 在默认回滚上限从 10 MB 扩大到 50 MB 的前提下，反而将物理内存占用降低了 70% 至 90%；macOS 空终端页面内存从 128 KiB 降至 16 KiB，隐藏 20 个标签页时的 GPU 内存更是从 385 MiB 骤降至 18 MiB。在性能端，团队发现 macOS 内核将每次伪终端（pty）读取硬性限制在 1 KiB 左右，于是改为双线程异步读取与解析，使 M4 Max 上的端到端 I/O 吞吐量提升了 25% 至 55%，cat 一个 150 MB 文本文件的耗时从 1.5 秒缩短至 566 毫秒。
单看更新日志会觉得这是一场性能狂飙，但如果放进第三方横向评测的坐标系里，就会发现 Ghostty 実は是在填补过往的坑。在此前针对旧版本的 Linux 独立基准测试（基于 ThinkPad T430、Arch/Hyprland 环境）中，Ghostty 的表现并不算出彩，尤其在内存占用和输入延迟上明显落后于头部竞品。
| 终端模拟器 | 内存占用 | 输入延迟 | 11MB 文本转储耗时 | Kitty 图形与动画协议 |
|---|---|---|---|---|
| Alacritty | 75 MB | 16.7 ms | 404 ms | 完全不支持 |
| Kitty | 91 MB | 18.3 ms | 401 ms | 100% 完整支持 |
| WezTerm | 130 MB | 30.8 ms | 1,246 ms | 支持图形，忽略动画控制 |
| Ghostty (旧版测试) | 174 MB | 38.3 ms | 407 ms | 1.4.0 起 100% 完整支持 |
即便在 10 月 15 日基于 M5 Pro 芯片对 Ghostty 1.3.1、Kitty 0.49.2 和 Alacritty 0.17.0 进行的 macOS 测试中，各家在不同负载下也只是互有胜负。目前尚未有针对 1.4.0 正式版的第三方独立横向跑分出炉，官方亮眼的纵向提升究竟能让它反超 Kitty 和 Alacritty，还是仅仅把 174 MB 的内存劣势拉回同一起跑线，仍是接下来最值得盯紧的变量。此外，1.4.0 还提前适配了 macOS 27 (Golden Gate) 的玻璃质感标签栏，并重构了 Linux GTK 端的 EGL/DMABUF 三重缓冲渲染管线，彻底解决了 125% 或 150% 分数缩放下的字体模糊顽疾。
10 个高危漏洞揭开终端“浏览器化”的代价
为什么一个用来敲命令的终端模拟器，会在一次版本迭代中集中爆出 10 个 GHSA 安全漏洞（截至发稿 GitHub 尚未分配完 CVE 编号）？答案恰恰藏在它引以为傲的富功能里。当现代终端开始原生集成图形渲染、OSC 52 剪贴板操作、OSC 8 超链接、Shell 深度钩子以及 tmux 控制模式时，终端解析器实际上已经变成了一个微型的 Web 浏览器。
现代终端每向富媒体和系统集成迈出一步，底层解析器就多背负一层等同于浏览器的远程攻击面。
仔细拆解这次披露的漏洞机制就会发现，许多攻击根本不需要用户执行恶意脚本，甚至不需要用户点击确认：
最危险的是两类零交互漏洞。在 1.3.1 及更早版本中，攻击者只需构造恶意的 Kitty 图形指令（GHSA-mhff-mv4q-fp63），只要用户在终端里显示了这段输出（比如查看远程日志），就能让 Ghostty 瞬间耗尽内存崩溃，在特定条件下甚至能越界读取或删除允许临时目录之外的本地文件；1.4.0 为此紧急将图形负载上限锁死在 65 MiB。同理，即便你的电脑上根本没有安装 tmux，恶意终端输出也能直接调用 Ghostty 内置的 tmux 控制模式解析器（GHSA-hcr9-7hcr-mjm8），通过构造零尺寸或超大尺寸窗格，一举轰塌整个 Ghostty 进程并关闭所有已打开的窗口。
另一类防不胜防的场景发生在日常开发动线里。当你从 GitHub 克隆了一个不可信的仓库并习惯性地敲下 cd 进入某个精心构造的目录名时，Ghostty 的 zsh/bash Shell 集成脚本就会被注入任意转义序列（GHSA-2r63-vmw6-3m3c），攻击者可以借此通过 OSC 52 协议静默替换你的系统剪贴板。而在粘贴保护机制上，旧版 Ghostty 漏掉了对回车符（\r, 0x0D）的换行判定（GHSA-4hwh-wx3w-3fqg），虽然日常交互式 Bash 或 Zsh 有括号粘贴保护，但一旦你正处于 sh、read 或部分 sudo/ssh 密码提示符等规范模式下，粘贴一段看似无害的文本就会直接绕过弹窗确认并执行命令。
- 风险.旧版本中的 Kitty 图形越界漏洞与 tmux 控制模式崩溃漏洞均属于底层解析缺陷，无法通过修改配置文件规避，停留在 Ghostty 1.3.1 及更早版本的开发者需立即升级至 1.4.0。
这场更新清楚地划出了当下终端模拟器赛道的分水岭。如果你只需要一个绝对安全、极低延迟的纯文本敲命令工具，砍掉一切花哨协议的 Alacritty 依然是最省心的防御性选择；但如果你既想要原生 macOS/GTK 的丝滑外观，又贪恋在终端里流畅预览高帧率图片、跨 SSH 自动同步配置，甚至在本次新增的 OSC 5522 协议下直接向终端粘贴图片，那么立即升级到 Ghostty 1.4.0 就是唯一的正解——毕竟已经有早期升级用户在社区反馈，此前在 tmux 内看图必崩的顽疾终于在这版画上了句号。