终端的语义层叠：几种终端方案的底层原理

物理终端#

早期计算机没有图形界面。用户通过物理终端与机器交互——一台独立的硬件设备，有键盘和显示器，通过串口连接到主机。DEC VT100 于 1978 年推出，它定义了大量至今仍在使用的控制序列标准。物理终端内部有自己的处理器和内存，接收键盘输入，向主机发送字符，接收主机返回的控制序列并在屏幕上渲染。

TTY#

TTY 是 Teletypewriter（电传打字机）的缩写。最早的终端确实是电传打字机——一台电动打字机，通过纸带和电话线与计算机通信。Unix 把这类设备抽象为 TTY 设备，在文件系统中表现为 /dev/tty1、/dev/tty2 等。

TTY 的核心功能：接收键盘输入传给连接的进程；接收进程的输出显示在屏幕上；处理基础编辑（行缓冲、回显、中断信号如 Ctrl+C）。

终端模拟器#

个人电脑普及后，终端模拟器取代物理终端——一个软件程序，模拟物理终端的行为。iTerm2、Alacritty、Kitty、macOS 自带的 Terminal.app 都是终端模拟器。

终端模拟器不做计算，只做三件事：接收键盘输入，转换成字节流发给 shell；接收 shell 输出的字节流，解析控制序列，在窗口中绘制字符；维护 scrollback 缓冲区保存历史输出。

shell、terminal emulator、multiplexer 的区别#

• shell（bash、zsh、fish）：命令解释器。输入的命令由它解析和执行。shell 不关心字符怎么画到屏幕上，只读写 TTY。
• terminal emulator（iTerm2、Alacritty、Kitty）：负责画字符、处理字体颜色、滚动、复制。它创建 PTY master，shell 运行在 PTY slave 上。
• terminal multiplexer（tmux、zellij）：在 shell 之上再套一层，管理多个会话、窗口、pane。它持有 PTY master，shell 运行在它创建的 PTY slave 上。

打开 iTerm2 运行 zsh：

1
iTerm2 (terminal emulator)
2
  └── PTY master
3
      └── zsh (shell) 运行在 PTY slave 上

在 iTerm2 里运行 tmux，tmux 里再运行 zsh：

1
iTerm2 (terminal emulator)
2
  └── PTY master (iTerm2 持有)
3
      └── tmux client
4
          └── UNIX socket
5
              └── tmux server
6
                  └── PTY master (tmux server 持有)
7
                      └── zsh (shell) 运行在 PTY slave 上

iTerm2 的 PTY master 连接的是 tmux client，不是 zsh；tmux server 持有另一个 PTY master，zsh 运行在它的 slave 端。

为什么需要 PTY#

物理终端时代，终端直接通过串口连接到主机。软件时代，终端模拟器和 shell 在同一台机器上运行，操作系统需要一种机制让它们通信，同时向 shell 呈现为一个真实的 TTY 设备。

PTY 就是为此设计的：一对虚拟设备（master 和 slave），slave 端对 shell 呈现为 /dev/pts/N 这样的 TTY 设备，master 端由终端模拟器持有。操作系统在内核中转发两端的数据。

PTY 是操作系统提供的虚拟设备对；终端和 shell 通过它转发字节流。shell 不必分辨物理终端和软件终端，终端模拟器也不必关心 shell 内部运行什么程序。

tmux 的解法：让 daemon 持有 PTY master#

tmux 让独立的 daemon 进程持有 PTY master。SSH 断裂只切断 tmux client 与 daemon 之间的 UNIX domain socket 连接；daemon 继续运行，PTY slave 上的进程不会收到 SIGHUP，继续执行。

UNIX domain socket 是一种进程间通信机制，工作在同一台机器的文件系统命名空间内，不经过网络协议栈。tmux client 和 server 通过这个 socket 交换消息，速度比 TCP socket 快。

terminfo 的内部结构#

一个 terminfo 条目可以用 infocmp 命令查看：

1
$ infocmp xterm-256color
2
#   Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm-256color
3
xterm-256color|xterm with 256 colors,
4
    am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
5
    colors#256, cols#80, it#8, lines#24, pairs#32767,
6
    bel=^G, blink=\E[5m, bold=\E[1m, clear=\E[H\E[2J,
7
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cud=\E[%p1%dB,
8
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA,
9
    dch=\E[%p1%dP, dl=\E[%p1%dM, ed=\E[J, el=\E[K,
10
    ...

二进制文件包含五个部分：

1. Header：包含 magic number（0x11A 或 0x21E，标识字节序）、name section 大小、boolean count、number count、string count、string table size
2. Name section：终端的主名称和别名，以 null 字节分隔
3. Boolean section：每个标志占 1 byte，值为 0 或 1。例如 am（auto margin，自动换行）、bce（background color erase，清屏时保留背景色）、km（has meta key）
4. Number section：每个数值占 2 bytes。例如 colors#256（支持颜色数）、cols#80（列数）、lines#24（行数）
5. String section：每个能力对应 string table 中的一个偏移量，指向实际的控制序列模板。例如 cup（cursor_address，移动光标）、clear（清屏）、smcup/rmcup（进入/退出 alternate screen）、kmous（鼠标支持）、setaf/setab（设置前景/背景颜色）

curses 库（Vim、htop、mutt 等工具的底层）在初始化时读取 $TERM，解析 terminfo 条目；屏幕绘制操作——移动光标、改变颜色、清屏——都使用 terminfo 定义的序列。

TERM 截获与能力降维#

tmux 默认设置 TERM=screen* 或 TERM=tmux-256color。下游程序查询 terminfo，读到的是 tmux 的能力集，而非 iTerm2、Alacritty 或 Kitty 的。

我第一次注意到这个问题，是在一台远程服务器上打开 Vim。本地 iTerm2 支持真彩色（set termguicolors 正常工作），但同一台机器的 tmux session 里，Vim 只能显示 256 色。查了一下，tmux 把 TERM 改成了 screen-256color，Vim 查到的能力集里没有真彩色支持。这就是 TERM 截获的直接后果。

终端控制序列是以 ESC（\x1b，ASCII 27）开头的字节流指令：

• CSI（Control Sequence Introducer）：ESC [ 开头，用于光标移动、颜色设置、清屏。例如 ESC [ 2 J 清屏，ESC [ 31 m 设置红色前景
• OSC（Operating System Command）：ESC ] 开头，用于与操作系统交互。例如 ESC ] 52 ; c ; <base64数据> ESC \ 将数据写入系统剪贴板（OSC 52）
• 鼠标报告：应用程序启用鼠标模式后，终端将点击事件编码为 ESC [ <按钮编码> ; <x> ; <y> M 发送给应用程序（SGR 1006 格式）
• 聚焦事件：终端获得或失去焦点时，向应用程序发送 ESC [ I 和 ESC [ O

tmux 截断、翻译或降级这些序列：

双 buffer 结构#

tmux 维护的 screen buffer 基于字符网格，与宿主终端的 scrollback 无关。

• scrollback：终端模拟器（iTerm2、Alacritty）维护的历史输出缓冲区。当屏幕上的内容被新输出推上去后，旧内容进入 scrollback。用户可以用鼠标滚轮、触控板或 Shift+PageUp 回溯查看，用鼠标选中后 Command+C 直接复制到系统剪贴板。
• copy-mode：tmux 自己的历史浏览机制。用户按前缀键加左方括号键进入，此时键盘事件被 tmux 消费，而不是发给 pane 内的应用程序。用 tmux 的键位导航：Space 开始选择，Enter 复制到 tmux 内部 buffer。这个 buffer 与系统剪贴板不直接互通；靠 OSC 52 或外部脚本才能把内容复制到系统剪贴板。

scrollback 由本地终端模拟器管理，copy-mode 由远程 tmux server 管理；数据不互通。

alternate screen 的模拟#

许多全屏 TUI 程序（Vim、less、htop）在启动时请求进入 alternate screen——独立的屏幕缓冲区。退出时切回主屏幕，原来的终端内容仍然可见。ESC [ ? 1049 h 和 ESC [ ? 1049 l 两个控制序列实现这个切换。

tmux server 在自己的 screen buffer 中模拟 alternate screen，不直接转发给宿主终端；鼠标滚动和文本选择由 tmux server 处理。

鼠标事件的多跳转发#

tmux server 先收到 X10 或 SGR 1006 鼠标事件，再决定消费、转发或进入自己的滚动逻辑。应用程序不再直接处理这些事件。

zellij 的 modal 输入系统#

zellij 也是 client-server 架构，daemon 持有 PTY master，但在 Rust 中内嵌了一个 WASM 运行时，插件以 WebAssembly 模块形式加载，可以编程访问 pane、tab 和状态栏。

它的输入系统是一个显式的 modal 状态机。同一套输入设备在不同”模式”下执行不同功能。Vim 同样使用 modal 输入——normal mode 下 j 向下移动光标，insert mode 下 j 插入字母 j。用户切错 mode，输入就路由到错误目标。

• Ctrl+p → pane mode
• Ctrl+t → tab mode
• Ctrl+s → scroll mode
• PageDown / PageUp 默认挂在 scroll mode 里

像 Codex 这样通过 node-pty 注入 ANSI 序列的 agent 不跟踪 zellij 的 mode 状态。我在 zellij 里运行 Codex 时，它发送的 PageUp 被 zellij 的 scroll mode 拦截，pane 内的程序根本没有收到这个序列。

node-pty 是 Node.js 的一个库，它在操作系统中创建 PTY pair，JavaScript 程序通过它像真实终端一样与 shell 交互：写入字节流，读取输出。Codex 通过它向 shell 发送键盘输入和控制序列，期望目标程序直接消费这些字节。zellij 可能把序列收进自己的 mode 处理，不转发给 pane 内的应用程序。官方文档提到 Unlock-First preset：modal 系统在该 preset 下拦截流向应用程序的输入。

cmux：本地终端与 JSON-RPC 控制#

cmux 用 Ghostty 的 Metal 渲染管线，是一个原生 macOS 终端，提供垂直标签页和 JSON-RPC socket API。

cmux 暴露了一个 socket 接口，外部程序向这个接口发送 JSON 对象来创建窗口、切换标签、查询状态。cmux 控制本地终端，不在远程机器上保持会话存活。

cmux 重启后只还原布局、工作目录和环境变量等元数据；pty 中运行的活跃进程状态不会恢复。

Domain：本地与远程 pane 的来源标记#

“domain”标记 pane 进程的来源：

• local domain：在本地机器启动进程
• ssh domain：通过 SSH 连接远程机器，启动 wezterm-mux-server
• tls / unix domain：连接已运行的 mux server

GUI 用同一套接口处理所有 domain 的 pane。远程 pane 和本地 pane 由同一个输入分发器处理，没有区别。

Damage tracking：从整屏推流到增量更新#

damage tracking 来自图形渲染：屏幕内容变化时，只重绘变化区域。WezTerm 把它用于终端远程传输。

mux server 维护每个 pane 的内部字符网格。当应用程序输出导致网格中的某些单元格发生变化时，server 只把这些变化的单元格——坐标、字符、颜色属性——打包发送给 GUI client。client 收到后，只更新对应的屏幕区域。

tmux 的 screen buffer 每次变化时，tmux server 把整个字符网格序列化为字符串，通过 UNIX socket 发送给 client。client 收到后，在自己的虚拟终端状态机中重新渲染。

mux server 管理 pty 和进程；GUI client 用 OpenGL、Metal 或 WebGPU 做本地渲染。两端通过 RPC 交换 damage tracking 更新和输入事件。

TERM 端到端穿透#

在 WezTerm 的远程 domain 中，远程机器上的应用程序看到的 TERM 仍然是 wezterm（或配置的等效值），中间 multiplexer 不会替换它。Kitty 键盘协议、Sixel 图形、Unicode width 的特定行为——只要 WezTerm 原生支持——穿透时不经中间层翻译。

Lua 配置的统一命名空间#

1
return {
2
  ssh_domains = {
3
    {
4
      name = "dev",
5
      remote_address = "myserver",
6
      remote_wezterm_path = "/home/user/.local/bin/wezterm",
7
    },
8
  },
9
  keys = {
10
    {
11
      key = "d",
12
      mods = "CMD",
13
      action = wezterm.action.ShowLauncherArgs { flags = "DOMAINS" },
14
    },
15
  },
16
}

ssh_domains 定义远程连接，keys 定义本地键位，flags = "DOMAINS" 弹出的 launcher 同时列出本地和远程 domain。

部署代价#

远程 domain/mux 通常在远程机器上也要部署 WezTerm 二进制文件，配置包含 ssh_domains、multiplexing、remote_wezterm_path 等选项。