如果你最近在技术社区里看到“Why are TUIs in trend”这么一个问题，很可能会心生疑惑：TUI 不是几十年前命令行时代的东西吗？为什么现在反而有一批新工具把它捡了回来？
TUI 是 Terminal User Interface 的缩写，也就是终端用户界面。它和普通 CLI 不太一样，普通命令是一次性输入、一次性输出；TUI 通常会在终端里展开一个完整界面，支持列表选择、面板切换、快捷键操作和实时刷新。htop、vim是很多人最早接触的 TUI 工具，而现在的btop、lazygit、lazydocker、ncdu、fzf这一类工具，也在不断强化终端里的交互体验。
我理解这件事的切入点不是“终端界面是否比图形界面好看”，而是“越来越多开发者的真实工作流仍然发生在终端里”。当工作流已经依赖 SSH、容器、配置文件、Git 和一组命令工具的时候，让操作界面尽可能接近工作流本身，往往比重新打开一个 Web 页面更高效。
下面我不讲太多抽象判断，只按实际工作里的观察拆一遍。
1. TUI 流行背后，首先是一个工作流问题
1.1 先分清 CLI 和 TUI
很多人容易把 TUI 和命令行当成同一个东西，但它们解决的问题并不相同。
命令行适合执行确定性的操作，例如“查看日志”“移动文件”“安装依赖”。这种操作交给命令后，结果直接打印在屏幕上，任务就结束了。它的问题在于，一旦任务包含多步判断，例如“先看进程列表，再选一个进程，再看它的资源占用”，纯 CLI 就非常难用。
TUI 的定位恰好是补上这段交互空白。它让程序在终端里保持运行状态，用户可以在里面上下选择、翻页、搜索、确认，再跳出执行动作。换句话说，CLI 是让用户写指令，TUI 是让用户在一个文本界面里做选择。
1.2 流行的不是花哨界面，而是“减少离开终端”
开发者的工作流通常不是在单一工具里连续完成，而是在编辑器、终端、浏览器、聊天工具之间来回切换。每次切换都有成本：你要重新找回上下文，确认窗口位置，等待界面加载，有时候还要重新输入命令。
TUI 能减少的并不是操作次数，而是切换次数。
比如处理 Git 仓库时，如果用命令行一个一个敲git status、git diff、git log，每一步都只能看到很小的信息片段。如果在 TUI 工具里看文件变更、暂存区、历史提交，整个过程都可以在同一块终端区域里完成，眼睛不需要反复跳转，键盘也不需要频繁切换。
这不是说每个工具都必须做成 TUI，而是说在终端内完成的事情越多，工作流越连续。
1.3 真正的信号：新工具开始选 TUI 作为默认形态
过去很多新工具默认提供 Web 管理界面，因为他们觉得 GUI 才适合展示复杂状态。但最近几年，一批面向开发者的工具把 TUI 当作第一优先级。
这不是产品经理忽然改变了审美，而是用户结构改变了。当工具的受众是程序员、运维、数据分析师时，这些人的常用运行环境可能就是一台没有图形桌面、只有 SSH 连接的服务器。这时 Web UI 再好看也没法直接用，TUI 反而成为所有机器上都可能存在的通用界面。
所以 TUI 的流行，并不是打了几场漂亮的演示战，而是它的运行场景变得和真实工作流重合了。
2. 推动 TUI 回暖的现实因素
2.1 远端环境让 TUI 成为默认可用界面
现在开发工作越来越多发生在容器、云主机、开发机、虚拟机里。很多时候真正运行代码的地方没有显示器，也没有浏览器窗口，只有 SSH 会话。
这种场景下，Web UI 的问题是端口和网络不一定方便暴露，桌面 GUI 则根本没有条件启动。TUI 不一样，它依赖的是终端、SSH 连接和文本渲染能力，只要连接没有断，就能工作。
使用 TUI 工具时，用户面对的操作对象和最终运行环境之间的隔阂非常少。你不用在本地下载文件、再导入到远端，也不用在浏览器和 SSH 窗口之间来回切换。它天然贴合“程序运行在服务器上”这一事实。
2.2 资源占用和启动速度被重新重视
TUI 流行的另一个原因是，大家开始重新在意一个工具从打开到可用的时间。
现代 Web 工具动辄需要加载几百 KB 甚至几 MB 的脚本，打开后还要构建界面框架、请求接口、渲染页面。对于一台性能不错的开发机，这些都能接受；但如果只是在服务器上看一眼日志，或者在 SSH 连接里管理文件，加载一个重型界面就显得很浪费。
TUI 工具通常没有浏览器渲染层，也不依赖 GPU，启动速度和内存占用都能控制得比较低。实测时你会发现，部分 TUI 工具启动时间比同功能的 Web 版本快了一个数量级，这种体感差异会直接影响你愿不愿意高频使用它。
这也是为什么很多工具作者优先做 TUI 而不是做 Web：他们希望用户把工具留在工作流里，而不是因为等加载而放弃。一个工具再强大，如果每次打开都慢，就会被慢慢淘汰。
2.3 键盘操作带来的专注感更容易被接受
TUI 的另一个特色是键盘优先。
鼠标操作适合随机访问和视觉扫描，键盘操作适合顺序执行和精确控制。TUI 工具把一组常用操作绑定到快捷键上，用户不需要把指针移动到某个按钮，也不需要把目光从当前位置移开，就能完成切换、确认、返回、退出这些动作。
这套交互在编辑器用户里已经很成熟。当越来越多开发者已经习惯用键盘操作编辑器时，他们自然希望做 Git、文件管理、容器管理时也能用同一套思维模型。TUI 把这种键盘交互从编辑器扩展到更多开发场景，整个工作流会显得更一致。
2.4 现代 TUI 开发成本比过去低了
往回看十年，想写一个稳定的 TUI 并不容易，需要处理终端转义序列、光标移动、重绘、键盘输入、窗口尺寸变化等问题。很多工具作者宁愿做 Web 界面，因为浏览器已经把页面渲染、事件处理、布局都封装好了。
过去这些年，TUI 开发工具链成熟了很多。部分框架提供了组件、状态管理和跨终端兼容能力，让开发者不需要从零处理所有底层细节。很多工具作者发现自己可以用很低的成本实现一个“足够好用”的终端界面，于是愿意做新的尝试。
不过需要说明的是，框架成熟并不代表 TUI 开发没有成本。布局、滚动、异步刷新、鼠标支持、粘贴行为、终端兼容性仍然需要踩坑，只是门槛降低了，越来越多个人项目和小团队愿意尝试。
3. 和 Web、桌面 GUI 放在一起，TUI 的边界在哪里
3.1 TUI 更擅长的事情
TUI 擅长的是“结构化文本操作”。
例如查看一个文件列表、查看系统资源、查看 Git 分支、查看容器状态、浏览日志。这些内容本质上都是结构化文本，天然适合用字符方式渲染。
在处理这类任务时，TUI 不仅有启动快、占用低的优势，还可以很好地嵌入脚本和终端快捷键组合。用户可以在一个 SSH 会话里启动 TUI，退出后又回到原来的 shell，不会破坏已有终端状态。
3.2 TUI 明显吃亏的地方
TUI 不适合复杂图形展示。
如果你想呈现的是一个折线图里的多个数据集、地理信息、流程图节点、高精度图表，或者需要用户频繁自由拖拽、缩放、并行比较，TUI 的表现力就不够了。虽然可以用字符拼出比较粗糙的图形，但视觉信息密度和交互自由度都远不如桌面 GUI 和 Web。
另一个弱项是普通非技术用户的学习成本。TUI 默认强调键盘，发现性差。普通用户进入一个图形界面后，会自然去找按钮；TUI 则要求用户先知道快捷键，或者花时间读帮助面板。面向大众的产品如果采用纯 TUI，往往会被认为不够友好。
3.3 用一张表看差距
| 维度 | TUI | Web UI / 桌面 GUI |
|---|---|---|
| 运行场所 | 已支持终端的环境 | 需要浏览器或桌面系统 |
| 启动速度 | 整体更快 | 可能出现加载等待 |
| 远端使用 | 天然适合 SSH | 需要端口、代理和会话机制 |
| 鼠标支持 | 有限或需要特殊模式 | 原生支持 |
| 图表表现 | 常用字符图，精度有限 | 视觉丰富 |
| 键盘效率 | 高 | 可以设计，但很多依赖鼠标 |
| 新手友好度 | 一般 | 更容易发现功能 |
| 开发成本 | 视功能复杂度决定 | 视功能复杂度决定 |
这张表不是为了证明 TUI 优于 GUI，而是说明它们覆盖的场景有交叉，但也有明显的偏好。真实工作里并不是任何工具都适合做成 TUI。
4. 哪些任务适合放进 TUI，哪些不适合
4.1 适合放进 TUI 的工作流
我从实际使用中总结，下面几类任务很适合用 TUI。
第一类是系统监控和状态查看。比如 CPU、内存、网络、磁盘占用。这类任务需要持续刷新，并且用户只做阅读和少量筛选，不太需要复杂排版。
第二类是 Git 操作和代码评审辅助。查看 diff、暂存文件、浏览提交历史、切换分支，这些操作在命令行里比较繁琐，在 TUI 里可以变成一组快捷键和列表。
第三类是文件管理、日志浏览和远程数据库操作。文件数量多、字段重复、信息量大的场景，TUI 能通过列表、筛选器和高亮降低信息阅读成本。
第四类是配置项较多的命令行工具。如果工具的参数表很长，用户经常依赖交互式搜索来确认下一步操作，TUI 这种“打开来选择”的交互可能比记忆长命令更好用。
4.2 不适合放进 TUI 的任务
我也见过不少刻意把工具做成 TUI 的案例，但效果并不一定好。
不适合做的任务通常有几个特征：面向非技术用户、需要大量自由绘图、需要多窗口并行拖拽、需要经常处理非纯文本文件、需要长期提供无障碍辅助能力。
如果用户群体更习惯打开浏览器，那么做一个 Web 界面可能更合理；如果核心价值是复杂图形展示，那么这个载体就选错了；如果一个操作只需要一个按钮和一两次点击，硬要做成 TUI 反而会增加复杂度。
4.3 判断标准其实很简单
我判断一个 TUI 值不值得做，主要看三点。
第一，用户是否已经处在终端环境里。如果用户本来就要打开浏览器，那么把功能塞进终端并不能省上下文。
第二，核心任务是否以键盘操作为主。如果核心任务是被动浏览，或者主要靠鼠标拖拽，TUI 的优势会减弱。
第三，终端是否适合承载输出。如果输出包含大量图片、颜色渐变、复杂排版，终端渲染可能会成为一种限制，而不是一种特色。
一个功能被做成 TUI 后，用户不会因为它“很酷”就愿意增加学习成本。真正留下来的工具，大多是因为它把一件原本很麻烦的事变成了一套连续键盘操作。
5. 想上手一个 TUI 工具，怎么验证它真的有用
5.1 从你每天都在做的操作里挑一个例子
如果你现在还不太确定 TUI 是不是值得学，我的建议是不要一次性学习很多工具。
先找一个你每天都要做、但每次都需要好几条命令才能完成的任务。比如“检查服务器负载并找出占用最高的进程”，或者“浏览 Git 历史查看某个文件什么时候被改过”。
然后找一个对应的 TUI 工具，只把它用在这一个任务上。多跑几次后，记录你完成这个任务需要几次按键、需要看哪些帮助信息、会不会经常退出界面去查命令。
这种验证方式比看演示效果更可靠，因为演示里的任务大多经过了筛选，真实工作里的情况往往更复杂。
5.2 用三个指标判断是否值得留下
第一是完成任务需要的时间。不要只看第一次使用的时间，要连续用几天之后再看。第一次很容易因为不熟悉快捷键变得很慢，但工具熟悉之后会不会变快，才是关键。
第二是错误率。在命令行操作时，你可能因为把参数拼错而执行了错误操作；在 TUI 里，如果操作可以分两步“先选中再确认”，往往有助于减少误触。
第三是上下文切换频率。这个指标很多人会忽略。一个 TUI 如果让你一次操作仍然需要回到命令行或网页去对照信息，说明它的边界没有覆盖整个任务流。
如果三个指标都没有改善，那就不要因为“它很终端风”而强行纳入工作流。
5.3 先检查终端环境，再决定要不要深入
不同 TUI 对终端能力的要求不一样。有的需要彩色输出，有的需要鼠标事件，有的需要特殊字体支持。如果你在某个终端里打开后界面错乱，不要先怪工具，请先检查自己的终端环境。
可以先用下面几个命令做一个基本检查：
echo $TERM tput colors stty size第一条输出当前终端类型，第二条输出支持的颜色数量，第三条显示当前终端行列数。许多 TUI 在设计时会针对这些能力做降级处理，如果你的终端能力太低，有些功能关闭或变慢是正常现象。
如果遇到显示错位，另一个原因是当前终端窗口太小。很多 TUI 可以处理不稳定布局，但极端窄的小窗口仍然会出现内容重叠或截断。遇到这种情况，先放大窗口，或者减少字体的行间距，再重新打开工具。
注意：如果你是在 SSH 会话里使用 TUI，还要注意网络延迟。延迟较高时，快速翻页或频繁触发刷新可能不够流畅，这时应优先选择支持渐进刷新和减少请求量的工具。
6. 如果自己做 TUI，第一版该怎么设计
6.1 第一版只做三件事
如果你正在考虑开发一个 TUI 工具，我的核心建议是：第一版不要想着做完整产品，只做三件事。
第一，键盘导航要通。用户能通过方向键或快捷键在列表项之间移动，当选项改变时，界面能正确刷新。
第二，状态要做出来。当前选中的是什么、程序正在处理什么、有没有出错，都要能在界面上看到，不能让用户一直猜。
第三，退出路径要明确。任何界面都应该随时可以退出，最好支持连续按两次 Esc、输入 q、或通过一个标准快捷键退出。如果一个 TUI 用户进去后不知道该怎样退出，这种体验基本上无法被接受。
这三点是我在测试终端工具时最看重的部分。功能可以慢慢增加，交互框架如果一开始就是错的，后面改起来会非常费力。
6.2 键盘布局和快捷键不要贪多
TUI 的快捷键容易越加越多，但用户能记住的其实有限。
我建议把操作分为三级来设计：
- 一级操作：在任意界面都能完成，例如退出、返回、刷新、查看帮助。
- 二级操作：当前页面里的核心动作，例如选择、确认、删除、打开详情。
- 三级操作：低频配置类动作，可以通过命令或右键菜单收起来，不必全部都占快捷键。
在实现时，每个页面最好只保留少量一级快捷键。如果快捷键之间还要用户翻帮助才能想起来，那么它设计得再丰富也没有实际效率。
另一个容易忽略的问题是快捷键冲突。有的终端程序本身就占用某些组合键，比如复制、粘贴、滚动。TUI 如果把这些组合键全部接管，用户会在终端操作和 TUI 内部操作之间产生混乱。建议给用户提供可配置键位映射，至少保证默认键位不覆盖终端的基础操作。
6.3 容易踩坑的四个细节
第一是终端宽度变化。用户在使用过程中可能会调小窗口，程序一定要监听 resize 事件并重新布局，否则界面会裂开。对于低端终端，还要考虑窗口特别窄时的降级策略。
第二是异步任务和界面刷新的关系。TUI 里最怕的是处理耗时任务时直接阻塞界面。用户点了按钮后，界面应该先给出反馈，后台任务再慢慢跑，跑完后把结果交回界面。如果整个过程都卡住，用户会以为程序崩溃了。
第三是彩色输出和终端兼容性。你可以使用十六色、256 色或者真彩色，但不同终端支持程度不同。尽量提供颜色关闭和降级模式，并且不要把语义完全建立在颜色上，因为总有人会在浅色终端或无颜色终端里使用。
第四是日志。TUI 用户不能像普通命令行那样直接看到所有打印日志，因为界面会占用整个屏幕。好的做法是把详细日志写入文件，或者在界面内提供日志查看面板。调试的时候，先看日志，再改参数。
注意：开发 TUI 时不要忘记非活跃模式。比如用户切换到其他窗口后，程序可能不能立即重绘；重新切回来时，界面如果还停留在旧状态，体验会很差。正确的做法是在重新获得焦点后强制刷新一次。
7. 判断这股热度的长期价值，要看什么
7.1 热度背后的真实变量
TUI 会不会一直热门，取决于它解决的痛点是否长期存在。
只要开发者还需要通过 SSH 连接服务器，只要程序还需要在容器里运行，只要工作流依然围绕终端展开，TUI 就一定有使用价值。它并不是为了复古，而是因为大量计算任务的入口仍然在终端。
一部分热度还来自开发工具的自我表达。近几年很多独立开发者喜欢做“小而美”的终端工具，因为生态和传播渠道非常集中。这类工具不一定都是为了效率，也带一些创作者的个人风格。对于使用者来说，重点不是看它属于哪个形式，而是看它能不能切入自己的工作流。
7.2 TUI 会大规模取代 GUI 吗
我认为不会。
TUI 和 GUI 各有明确边界。展示复杂数据、服务普通用户、需要精美视觉反馈时，GUI 仍然有不可替代的优势。TUI 也不会只停留在旧式工具上，而是会继续演化，例如鼠标支持、颜色分级、状态栏、异步刷新等能力都会越来越完善。
未来更可能出现的形态是“同一个工具提供多个前端”：复杂管理用 Web，快速操作用 CLI，日常浏览定制用 TUI。这种选择不是倒退，反而是对场景更细颗粒度的区分。
7.3 吸收趋势而不是照搬形式
当你看到一堆项目在做 TUI 时，最适合跟进的方式不是把所有工具都换成 TUI，而是先想清楚自己的工作流里哪里存在连续切换。
如果切换成本主要来自“命令太零碎，信息太分散”，TUI 可能确实有帮助。如果切换成本来自复杂内容和团队协作，那么把界面做成 TUI 并不会解决问题。
对一个开发者而言，TUI 带来的一个更实际的价值是：你可以把大量操作沉淀成一套稳定的键盘工作流，不受图形界面布局变化影响。选择工具时，优先看它的默认工作流是否和你一致，而不是它表面是否跟得上潮流。
踩过几次之后我发现，很多看起来“工具形态新”的问题，回到使用场景里其实就是两件事：信息在哪儿，操作是否连续。TUI 只是回答这两个问题的一种方式，适合的时候很好用，不适合的时候也真没必要硬凑。
