终端复用器（Terminal Multiplexer）是开发者日常工作中不可或缺的工具。从 GNU screen 到 tmux，这些工具的核心价值在于会话持久化 —— 让进程在 SSH 断开后继续运行，并在重新连接时恢复界面状态。然而，这个看似简单的功能背后隐藏着一个长期被忽视的技术债务：每个复用器都必须实现自己的终端模拟器来解析和存储输出状态。
终端复用器的技术债务
传统终端复用器如 screen 和 tmux 都采用相似的架构：它们创建一个伪终端（PTY），将所有子进程的输出通过内部的终端模拟器解析，维护一份屏幕状态，然后在客户端连接时根据这份状态重新绘制界面。问题在于，这些内置模拟器往往落后于现代终端的能力。
screen 的终端模拟器诞生于几十年前，面对现代程序输出的复杂转义序列（如光标形状变更、RGB 颜色、Kitty Graphics Protocol 等），它要么直接丢弃无法识别的序列，要么错误解析导致渲染异常。当用户重新连接到 session 时，看到的界面往往与实际运行状态存在偏差，特别是运行 TUI 应用（如 Vim、Helix、lazygit）时，界面错位或字符丢失是常见问题。
tmux 虽然在这方面做得更好，但它选择了不同的架构哲学：一个服务器进程服务多个客户端，提供窗口布局、滚动历史、复制模式、状态栏等完整的工作空间功能。这种设计带来了强大的功能，但也增加了复杂性和学习成本。
libghostty-vt：剥离的终端核心
Ghostty 终端模拟器的作者 Mitchell Hashimoto 在 2025 年提出了 libghostty 的愿景：将 Ghostty 经过生产环境验证的终端模拟核心剥离为可嵌入的库。首个发布的组件是 libghostty-vt，一个零依赖（甚至不依赖 libc）的库，提供终端序列解析和状态维护的 C API。
libghostty-vt 继承了 Ghostty 的核心优势：SIMD 优化的解析性能、完善的 Unicode 支持、经过模糊测试和 Valgrind 验证的代码质量，以及对现代协议（如 Kitty Graphics Protocol、Tmux Control Mode）的完整支持。最关键的是，它维护的终端状态与真实 Ghostty 终端的显示行为完全一致。
对于终端复用器开发者而言，这意味着不再需要维护自己的模拟器代码，而是可以复用一个经过大规模用户验证、持续更新的终端核心。这正是 Boo 项目的技术基础。
Boo 的架构选择
Boo 由 Coder 团队的 Kyle Carbs 开发，明确定位为 "GNU screen 风格的终端复用器"。与 screen 类似，Boo 采用 1 server to 1 client fork 的架构模型：每个客户端会话是服务器进程的一个 fork，而非 tmux 那种 n clients to 1 server 的多对一模型。
这种架构选择体现了 Boo 的极简哲学：只提供会话管理和前缀键功能，不实现窗口布局、状态栏、复制模式等额外功能。正如作者在 Hacker News 上的解释："screen 的魅力在于它几乎不做这些事情 —— 会话、前缀键，仅此而已。Boo 保持这个模型，只是将模拟器替换为 libghostty，让重连时的重绘真正正确。"
libghostty-vt 的引入解决了传统复用器的核心痛点：保存的终端状态与实际终端显示一致。当 TUI 应用在 Boo session 中运行时，即使客户端断开连接，libghostty-vt 维护的状态也能准确反映应用的真实界面。重新连接时，用户看到的是与断开前完全一致的画面，不会出现字符错位或样式丢失。
此外，由于 libghostty-vt 能正确响应终端查询序列，TUI 应用在 detached 状态下不会陷入等待终端响应的挂起状态，这对于自动化场景尤为重要。
工程实践与部署考量
对于考虑采用 Boo 的工程团队，需要评估以下要点：
平台支持：libghostty-vt 目前主要支持 macOS 和 Linux（x86_64/aarch64），Windows 支持仍在计划中。如果你的基础设施包含 Windows 服务器，需要等待或寻找替代方案。
功能边界：Boo 不是 tmux 的替代品。如果你依赖 tmux 的窗口布局、会话共享（tmux attach 多客户端同时连接）、或插件生态，Boo 可能无法满足需求。但如果你只需要 screen 风格的简单会话持久化，Boo 提供了更现代的实现。
兼容性：作者明确表示 Boo 目前 "不是 GNU screen 的 drop-in 替代品"。迁移现有 screen 工作流时，需要测试关键用例，特别是涉及复杂 TUI 交互的场景。
组合使用：Boo 的架构允许组合使用 —— 一个 Boo session 就是一个运行程序的 PTY，因此你完全可以在 Boo session 内部再运行 tmux，这为用户提供了渐进迁移的可能性。
现代终端基础设施的趋势
Boo 的出现反映了终端基础设施领域的一个重要趋势：终端模拟能力正在从应用层下沉为可复用的库层。libghostty 的愿景不仅服务于终端复用器，还包括 IDE 内置终端（如 VS Code 的 Xterm.js、JetBrains 的 jediterm）、CI/CD 日志渲染、Web 端终端展示等场景。
对于终端复用器而言，这种分层架构的优势显而易见：终端模拟的正确性和性能由专门的库保障，复用器可以专注于会话管理、网络传输等自身核心功能。随着 libghostty API 的稳定，我们可能会看到更多基于该库的终端工具出现，形成围绕现代终端核心的生态系统。
Boo 目前处于早期开发阶段，但其架构理念值得关注。对于追求极简、重视 TUI 应用正确渲染的开发者，它提供了一个 screen 的现代替代品；对于更复杂的窗口管理需求，tmux 仍然是更成熟的选择。关键在于理解各自的技术取舍，选择适合团队工作流的工具。
参考来源
- Mitchell Hashimoto, "Libghostty Is Coming", 2025: https://mitchellh.com/writing/libghostty-is-coming
- Hacker News 讨论，"Show HN: Boo – Screen-style terminal multiplexer built on libghostty": https://news.ycombinator.com/item?id=48496250
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。