字符界面 TUI

上一节的命令行是"一问一答"，说完就散。但你一定见过另一种东西：在同一个黑窗口里，居然出现了会实时跳动的彩色条形图、能上下选择的文件列表、能分屏的编辑器。它们不是图形界面，一个像素都没有——TUI 是纯粹用字符搭出来的界面。它是命令行和图形界面之间那个被严重低估的中间物种，而且这几年正在强势复兴。

先把这一节的黑话全翻译一遍

这节的术语密度比上一节高，而且大多是缩写。先一次性换成大白话，后面就不会卡。

• TUITUI（Text-based User Interface，文本用户界面——在只能显示文字的黑窗口里，用字符拼出来的界面）。说白了就是：拿一个个汉字和符号当积木，在屏幕上摆出边框、按钮和图表的样子。
• CLICLI（Command-Line Interface，命令行界面——你说一句、它答一句，不重画屏幕的那种）。上一节讲过，这里当参照物用。
• GUIGUI（Graphical User Interface，图形用户界面——有窗口、图标、鼠标箭头的那种）。下一节的主角。
• 字符网格终端窗口的本质：一张横多少格、竖多少格的方格纸，每格只能填一个字符。听着玄，其实就是小学生用的田字格本，只不过它有 80 列 24 行。
• ANSI 转义序列ANSI 转义序列（ANSI Escape Sequence，一串以特殊字符开头的"暗号"，用来指挥终端把光标挪到哪、换成什么颜色）。打个比方，这就是写在稿件旁边的红笔批注："此处换红色""跳到第 5 行"——批注本身不印出来，但它决定了印出来的样子。
• 光标光标（Cursor——下一个字符将要落在哪一格的那个标记）。它相当于你手里那支笔的笔尖位置。TUI 的一切魔法，本质都是"把笔尖挪到指定格子，然后写一个字"。
• ASCIIASCII（American Standard Code for Information Interchange，美国信息交换标准代码——最早的一套字符编号表，一共 128 个字符）。简单说就是最初那份"字符花名册"：英文字母、数字、标点、几个控制符号，仅此而已，连汉字都没有。
• ncursesncurses（new curses，一个替你处理转义序列和屏幕刷新的老牌 C 语言库）。它干的活儿相当于装修队里的工头：你说"这儿要一面隔断墙"，他去决定用什么料、怎么砌、几点收工。
• 终端复用器终端复用器（Terminal Multiplexer，比如 tmux——把一个终端窗口切成好几块，还能在你断线后替你保管现场）。好比把一间办公室用隔断分成四个工位，而且你下班后东西不会被收走。

TUI 卡在哪个位置：CLI 和 GUI 之间的那一格

很多人对 TUI 的疑惑其实是"它到底算命令行还是算图形界面"。答案是都不算，它是独立的第三种。用一张表把三者钉在各自的格子上：

看第 3 行和第 5 行你就会发现一件有意思的事：TUI 在"长相"上像 CLI，在"骨架"上像 GUI。它显示的东西是字符，所以能塞进 SSH 这种窄通道；但它的程序结构是"停在那儿等你按键"，跟图形界面一模一样。

换成大白话打个比方。CLI 好比窗口办事的柜台：你递一张单子，办事员盖章还你，一次一来一回，办完各走。GUI 好比装修好的自助大厅：所有业务的指引牌、取号机、显示屏都摆在那儿，你随便逛随便点。而 TUI 是那种老式的电话客服：全程只有声音（只有字符），但你能"按 1 查余额、按 2 转人工"，界面一直在，随时响应——它的通道极窄，交互却是活的。

终端里怎么"画"界面：字符网格

要理解 TUI，先要接受一件事：终端窗口本质上是一个二维字符网格。它不像浏览器那样有一个自由的像素坐标系，它只有"第几行第几列"。一个典型终端是 80 列 × 24 行，也就是 1920 个格子，每个格子只能装一个字符，外加几个属性：前景色、背景色、粗体、下划线、反色。

普通命令行程序对这个网格的用法非常保守：只在最后一行往下追加，写过的地方永不回头。像一条只会往前流的河，历史内容滚上去就不管了。

而 TUI 程序做的是完全不同的一件事：它把整个网格接管下来当成画布，可以随时跳到第 5 行第 12 列去改一个字符，可以整屏重绘，可以每秒刷新十次。这就相当于从"写日记"变成了"画画"——同一张纸，可以擦了重画。

下面是一个 TUI 界面在字符层面的真实样子，你看到的"框"其实只是一些制表符字符：

┌─ Processes ──────────────────────────────┐
│  PID  USER    CPU%   MEM%  COMMAND       │
│ 1024  root     3.2    1.1  systemd       │
│ 2048  alice   68.5   12.4  node          │  ← 反色高亮 = 当前选中行
│ 3072  bob      0.7    0.3  bash          │
├──────────────────────────────────────────┤
│ CPU [||||||||||||||||......]  72%        │  ← 用 | 和 . 拼出的进度条
│ MEM [||||||||............]    41%        │
└──────────────────────────────────────────┘
 F1 Help  F5 Tree  F9 Kill  F10 Quit          ← 底部功能键提示条

1920 个格子到底是多是少：把数字换算成能摸到的量

上面提到"80 列 × 24 行 = 1920 个格子"，这个数字听着没感觉。换算一下你才知道 TUI 是在多窄的地方施展本事。

• 1920 个格子有多少相当于一张 A4 纸上手写 24 行、每行 80 个字——差不多是一页信纸的容量。TUI 要在这一页纸上同时放下标题、边框、表格、进度条、状态栏和功能键提示，还要能滚动、能高亮、能选中。这就像在一张便签上画完整栋楼的平面图，每一格都得算计。
• 同一块屏幕，GUI 有多少格同样大小的窗口，图形界面按像素算大约是 640 × 384，也就是 24 万多个可独立上色的点。也就是说 GUI 手里的"格子"是 TUI 的一百多倍。换算成画画：TUI 手里是一盒 24 色蜡笔在便签上画，GUI 手里是喷枪在整面墙上画。
• 4K 屏幕的差距更夸张一块 4K 屏有 3840 × 2160 约 830 万个像素点。这是个什么量级？如果让你在方格纸上手工给每个格子涂色，一秒涂一个不休息，需要连续涂 96 天；把这些格子摊开成方格纸，大约要用掉2000 多张 A4 纸。而 TUI 只用其中不到两千格就把一个可交互的监控面板做出来了。
• 传输量的差距TUI 刷一次全屏，最多传 1920 个字符加上颜色暗号，几 KB 而已，相当于一条短消息的体量。GUI 远程传一帧 4K 画面，压缩后还有几百 KB 到几 MB，相当于发一张高清照片。你在信号只有一格的地方，短消息发得出去，照片就卡在那儿转圈——这就是 SSH 场景下 TUI 完胜的全部原因。

所以 TUI 的设计哲学可以一句话概括：格子极少，所以每一格都必须有信息量。这也解释了为什么 htop 那种界面看着"密"——不是设计师不懂留白，是他真的没有格子可以浪费。好比在一间只有六平米的小屋里装修，你不会摆装饰品，每一寸都得是收纳。

字符画怎么"画"出边框：那些不是图形的图形

看回上面那个 htop 样子的例子，那些漂亮的框线是怎么来的？答案很朴素：它们就是字符，跟"啊"和"A"是同一类东西，只不过长得像线。

这批字符分三代，一代比一代好看：

第三代那个"半格"技巧特别值得说，因为它是 TUI 里最巧的一手。▀ 这个字符只占格子的上半部分，▄ 只占下半部分。于是聪明的做法出现了：把上半格设一个前景色，下半格设背景色，一个格子就变成了两个独立可上色的点。垂直分辨率凭空翻倍。btop 那种看着像真正折线图的曲线，就是这么榨出来的。

这一手就像宿舍里搭上下铺：房间面积没变，睡的人翻了一倍。技术上什么都没多，只是把原来"一格一个用途"的假设打破了。

纯 ASCII 版（最保守）        制表符版（主流）           方块图表版（最花）
+---------------+          ┌───────────────┐          ▁▃▅▇█▇▅▃▁▁▃▅▇
| CPU  [####..] |          │ CPU  ████░░░░ │          ▂▄▆█▆▄▂▁▂▄▆██
| MEM  [##....] |          │ MEM  ███░░░░░ │          CPU 72%  MEM 41%
+---------------+          └───────────────┘          用半格字符逼近折线

还有一个必须提醒的坑：汉字占两格。一个英文字母占一格，一个汉字在终端里占两格宽。所以你用汉字做界面，算宽度时得按两倍算，否则框线会错位——这就是很多中文 TUI 界面框线歪掉的原因。好比装修贴瓷砖，你按小砖的尺寸排好了图，结果送来的是大砖，整面墙的缝就全对不上了。

ANSI 转义序列：控制光标的那套暗号

问题来了：字符是通过一根管道流进终端的，程序怎么告诉终端"接下来这个字符请写到第 5 行第 12 列，用红色"？管道里只能流字符，没有额外的控制通道。

答案是一套非常聪明也非常古老的约定：ANSI 转义序列。约定的核心是选一个几乎不会出现在正常文本里的特殊字符 ESC（ASCII 27）当作"暗号开头"。终端一看到 ESC[ 这个组合，就知道：后面跟着的不是要显示的内容，而是给我下的命令。

有了这套暗号，"画界面"就变成了一件机械活：清屏 → 跳到某格 → 设颜色 → 输出字符 → 再跳下一格。用最原始的 shell 就能验证：

# 清屏，然后在第 5 行第 20 列打印一行红色反色文字
printf '\033[2J\033[5;20H\033[31;7m Hello TUI \033[0m\n'

# 用一个死循环把秒数刷在同一个位置上（原地更新，不换行）
while true; do
  printf '\033[3;1H当前时间：%s' "$(date +%T)"
  sleep 1
done

注意第二个例子里的关键点：它每次都跳回同一个位置覆盖写。屏幕上看起来是"时间在原地跳动"，实际上只是不停地重写那一小块格子。所有 TUI 动画的原理都是这个：反复擦掉重画，快到让你以为它在动。

ncurses：不用再手写暗号的那层封装

直接手写转义序列写一个 htop，理论上可行，实际上是噩梦。原因有三个：不同品牌的终端支持的序列不完全一样（VT100、xterm、Windows 控制台各有差异）；每帧全屏重绘会导致明显的闪烁；还要自己处理窗口大小变化、键盘特殊键、鼠标事件等一堆杂事。

于是 1980 年代出现了 curses，后来演化成今天几乎所有 Unix 系统都自带的 ncurses（new curses）。它是 TUI 世界的"图形库"，解决了四个核心问题：

• 终端能力抽象通过 terminfo 数据库查询"当前这个终端支持什么"，你只管调 move(5, 12)，它负责翻译成这个终端听得懂的具体序列。
• 虚拟屏幕与差分刷新你所有的绘制都写进内存里的一块虚拟屏幕，调用 refresh() 时它只把和上一帧不同的格子发给终端。这是消除闪烁的关键，也大幅节省带宽。
• 窗口（window）抽象可以把屏幕切成若干矩形区域，各自独立绘制、独立坐标系，互不干扰——这就是"分屏"的底层能力。
• 输入处理把方向键、F1~F12、Home/End 这些会发出多字节序列的按键，统一识别成一个个键码；还能关闭回显和行缓冲，做到"按一下键立刻响应"而不必等回车。

一段最小的 ncurses 程序长这样，你会发现它的心智模型已经很接近图形界面编程了：

#include <ncurses.h>

int main(void) {
    initscr();              // 接管屏幕，进入 TUI 模式
    noecho();               // 按键不回显
    curs_set(0);            // 隐藏光标
    keypad(stdscr, TRUE);   // 允许识别方向键等特殊键

    mvprintw(2, 4, "请用 ↑↓ 选择，q 退出");
    box(stdscr, 0, 0);      // 给整屏画一个边框
    refresh();              // 差分刷新：只发送变化的部分

    int ch;
    while ((ch = getch()) != 'q') {   // 事件循环：等按键
        mvprintw(4, 4, "你按了键码：%d   ", ch);
        refresh();
    }

    endwin();               // 归还屏幕，恢复原样
    return 0;
}

请留意 while ((ch = getch()) != 'q') 这一行——这是一个事件循环：程序不再从上往下跑完就退出，而是停在那里等你动作，你按一下它响应一下。这个思路和后面 § 1.5 要讲的 GUI 事件驱动本质上是同一件事。也就是说，TUI 虽然长得像命令行，但它的编程范式已经站到 GUI 那一边了。

TUI 的操作范式：为什么全靠键盘，还搞出"模态"

TUI 没有鼠标（大多数情况下），这不是缺陷，而是逼出了一套完全不同的操作哲学。理解它，你才不会觉得 vim 是反人类。

核心矛盾是这样：键盘只有一百来个键，但一个软件要提供几百个功能。怎么办？三条路。

• 路一：组合键用 Ctrl、Alt、Shift 当"档位"，把一个键变成好几个。Ctrl+S 和 S 是两回事。这就像汽车的挂档：油门只有一个，但一档和五档下踩同样深度，车的反应完全不同。
• 路二：前缀键先按一个"引导键"进入某个分类，再按第二个键选具体功能。tmux 全靠这一招：先按 Ctrl+B，再按 % 竖着切窗、按 " 横着切窗、按 D 离开。这就是电话客服的"按 1 转账、按 2 查询"：先进一层菜单，再选具体项。
• 路三：模态最激进的一招，也是 vim 的招牌。模态（Modal，模式——同一个键在不同模式下含义完全不同）说白了就是：给键盘装了个"档位开关"。在"普通模式"下按 D 是删除，在"插入模式"下按 D 就是打出一个字母 d。

模态这件事新手最反感，但它的逻辑其实很硬：既然键不够用，那就让同一批键在不同场合复用。打个比方，这好比医院里同一间诊室，上午是内科门诊、下午是抽血室——房间没变，挂的牌子变了，进去要办的事就完全不同。你要是不看牌子就闯进去，当然会懵。vim 屏幕左下角那个 -- INSERT --，就是那块牌子。

vim 的三个主要模式，用一句人话各自说清：

为什么专业用户愿意付这个学习成本？因为收益是可组合性。d 是删，w 是一个词，3 是三次——于是 d3w 就是"删掉后面三个词"。你没有单独学过 d3w 这个功能，它是三个零件拼出来的。这和上一节命令行的管道是同一个思路：给你一堆小零件，让你自己组装，而不是给你一个装好的按钮。图形界面里"删掉后面三个词"这个功能，如果开发者没做，你就永远做不到。

TUI 与 GUI 的效率之争：谁快其实取决于问谁

这个争论吵了三十年，之所以吵不清，是因为双方在比不同的东西。把它拆成三个不同的问题，答案立刻清楚。

关于那个"鼠标 1 到 2 秒、快捷键 0.2 秒"的差距，值得换算一下才有感觉。假设你每天做 300 次这种小操作，每次省 1 秒，一天省 5 分钟，一年省下大约 30 个小时——差不多是四个完整工作日。这就是为什么重度用户愿意花两周去啃 vim 的快捷键：学习成本是一次性的，效率收益是每天复利的。

但请不要把这条推到荒谬的地步。打个比方：专业厨师用中式菜刀能同时切片、拍蒜、剁馅，比一柜子专用工具都快；但你只是周末做一次饭，买一把菜刀再练三个月刀工，完全不值。工具的效率上限，只对天天用它的人有意义。判断标准很简单：这件事你一年做几次？做三次就用图形界面，做三千次就该学快捷键。

那些你一定见过的 TUI 代表作

这里面 tmux 值得多说一句，因为它是"TUI 里再跑 TUI"的典型：它自己是一个字符界面程序，同时又把屏幕切成好几块，每块里再跑别的程序（可能又是一个 TUI）。它扮演的角色，其实就是终端世界里的窗口管理器——和桌面上负责给窗口排版、切换焦点的那个组件一模一样。

五个代表作巡礼：它们各自解决了什么问题

上面那张表只说了"是什么"，这里说"为什么它值得存在"。挑五个最有代表性的，各配一个生活场景。

• htop / btop · 实时资源监视它替代的是"每隔两秒敲一次 ps"这种傻办法。它干的活儿相当于医院监护室床头那台仪器：心率、血压、血氧连续画在屏幕上，护士一眼扫过就知道有没有异常。btop 更进一步，用半格字符画出了真正的折线趋势图。
• vim / neovim · 文本编辑器它解决的是"服务器上没有图形编辑器，但我得改一个配置文件"。好比工地上没有办公室，工头就在墙上贴张图纸直接改——工具简陋，但现场就能办完，不用跑回公司。
• lazygit · Git 可视化操作Git 的命令行很强但很绕，图形客户端又装不到服务器上。lazygit 把分支、提交历史、暂存区并排摆成几块面板，按空格就能把某一行代码单独加入暂存。这就像超市收银台的分拣：一堆商品摆在传送带上，你挑哪几件先结账，看着挑、点着来，不用背商品编号。
• Midnight Commander · 双栏文件管理器左右两栏，左边源、右边目标，按一个键就对拷。这个布局是 1986 年 Norton Commander 定下来的，四十年没人能改进——因为它精确匹配了人搬东西的心智模型：好比搬家时地上摊开两个纸箱，从这箱拿到那箱。
• tmux · 终端复用与会话保管它解决两件事：把一个窗口切成多块，以及断线后现场还在。第二件才是杀手级的。它相当于快递驿站：你人不在家（网断了），包裹（正在跑的任务）不会被退回，寄存在那儿，你什么时候回来什么时候取。没有 tmux，网一断任务就死，这在跨国运维里是致命的。

看完这五个，你会发现一个共同点：它们全都出现在"人在这头、机器在那头，中间只有一根细管子"的场景里。这不是巧合，这就是 TUI 的生态位。

为什么 SSH 场景下 TUI 无可替代

这是 TUI 存在的最硬的理由，也是它永远不会消失的原因。设想一个真实场景：凌晨三点，你收到告警，要连到新加坡机房的一台服务器上排查内存暴涨。你手上只有笔记本和一个不太稳的网络。

• 带宽差距是三个数量级TUI 一次全屏刷新只要传几 KB 字符；把图形界面画面通过 VNC / 远程桌面传过来，是每秒几 MB 的视频流。网络一抖，图形远程桌面直接卡成幻灯片，TUI 依然顺滑。
• 服务器根本没有图形环境生产服务器为了安全和省资源，通常连桌面都没装。你想用图形工具，得先给它装一整套 X11 或桌面环境——这本身就是不可接受的风险和开销。
• SSH 通道天生就是字符流SSH 传输的就是终端字符，TUI 是它的"原生格式"，不需要任何额外协议、端口、代理。图形转发（X11 forwarding）能做但极其笨重且脆弱。
• 断线可续配合 tmux 或 screen，网断了重新连上，你的界面还在那里，跑了一半的任务没有中断。图形远程会话一断往往就死了。
• 既有交互又有实时CLI 打印一次静态快照不够看趋势，图形界面又用不上。TUI 恰好填住这个空档：htop 让你在纯字符通道里获得了"实时可交互仪表盘"。

所以 TUI 的生态位可以一句话概括：当你只有一根字符通道，却需要一个界面的时候，TUI 是唯一的答案。

现代 TUI 复兴：它其实正在变年轻

你可能以为 TUI 是上世纪的遗产，只剩老工具在苟活。恰恰相反，2020 年之后 TUI 出现了明显的第二春，原因有三个：云原生时代大家天天泡在终端里；ncurses 的 C 语言 API 太痛苦而新语言给出了现代方案；开发者工具的用户本来就是键盘重度用户，TUI 的操作效率反而更高。

最能说明趋势的是 Textual 和 ink：一个把 CSS 搬进了终端，一个把 React 搬进了终端。这意味着Web 前端二十年积累的界面开发范式，正在被反向移植回字符网格。写 TUI 不再是和转义序列搏斗，而是像写网页一样声明"我要一个居中的、带边框的、占 30% 宽度的面板"。

看一眼 Textual 的写法，你几乎会以为在看前端代码：

from textual.app import App, ComposeResult
from textual.widgets import Header, Footer, Button, Static

class DemoApp(App):
    CSS = """
    Static { border: round green; padding: 1 2; width: 60%; }
    Button { margin: 1; }
    """
    def compose(self) -> ComposeResult:
        yield Header()
        yield Static("这是一个终端里的面板，样式由 CSS 控制")
        yield Button("点我", variant="success")
        yield Footer()

    def on_button_pressed(self) -> None:      # 事件回调
        self.query_one(Static).update("按钮被按下了！")

DemoApp().run()

顺带说一句，现在你用的很多命令行工具其实已经悄悄是 TUI 了：npm install 那个会动的进度条、docker pull 里多层并行更新的下载条、AI 编程助手在终端里的对话框——它们都在用光标定位原地重写，都是 TUI 技术。TUI 早已渗透到你每天的工作流里，只是你没给它起名字。

自己动手做一个 TUI：三条难度不同的路

看到这儿你可能想试试。Python 生态里正好有三条路，难度从"折磨"到"愉快"依次排开，正好对应了 TUI 开发四十年的进化史。

给一条实用建议：只想让脚本的输出好看点，用 rich；想做一个能上下选择、有多个面板的真界面，用 textual；除了学习和维护老代码，别再从零写 curses 了。这就像今天没人会自己烧砖建房——不是因为烧砖不光荣，而是有更好的现成材料。

下面是三条路各写一小段，你可以直接感受一下代码量的差距。同样一件事：在屏幕上显示一个带边框的面板，里面写一行字。

# 路一：curses —— 坐标全靠自己算
import curses

def main(scr):
    curses.curs_set(0)                      # 隐藏光标
    h, w = scr.getmaxyx()                   # 先问清屏幕多大
    box = scr.subwin(5, 40, h//2 - 2, w//2 - 20)   # 自己算居中位置
    box.box()                               # 画边框
    box.addstr(2, 4, "Hello from curses")   # 自己算文字位置
    scr.refresh(); box.refresh()
    scr.getch()                             # 等一个按键

curses.wrapper(main)


# 路二：rich —— 一行就有边框和居中
from rich.console import Console
from rich.panel import Panel

Console().print(Panel("Hello from rich", title="面板", expand=False))


# 路三：textual —— 声明式，写起来像网页
from textual.app import App, ComposeResult
from textual.widgets import Static

class Demo(App):
    CSS = "Static { border: round green; width: 40; align: center middle; }"
    def compose(self) -> ComposeResult:
        yield Static("Hello from textual")

Demo().run()

注意这三段的心智负担差别，而不是代码行数。curses 那段里，你脑子里得同时装着"屏幕多大、面板多大、除以二居中、文字往里缩几格"这一堆算术；textual 那段你只是说"我要一个 40 宽、绿色圆角边框、居中的东西"，剩下的框架去算。这个转变就是从"手工计算"到"声明意图"，也是整个界面开发史的主线。好比点菜：一个是你自己进厨房按克数配料，一个是你只说"要一份微辣的"。