命令行 CLI

很多人第一次看到那个黑底白字、只有一个光标在闪的窗口时，第一反应是"这不是上世纪的东西吗"。恰恰相反：命令行不是被淘汰的过去，而是至今没有替代品的现在。所有服务器、所有代码仓库、所有自动化流水线的底层，跑的都是一行行命令。这一节我们把它彻底讲清楚：它是什么、它凭什么活到今天、以及它真正的短板在哪。

开篇先把这些词翻译成人话

这一节会反复出现几个词。为了后面读得顺，先一次性把它们换成大白话，每个词后面那句括号才是你真正要记住的东西。

• CLICLI（Command-Line Interface，命令行界面——只能打字、没有图标可点的那种界面）。说白了就是：屏幕上除了一个光标啥也没有，你想让机器干活，只能把要求打成一行字。
• 终端 Terminal终端（Terminal，终端窗口——负责显示字符、接收你敲的键盘）。它干的活儿相当于餐厅里那张点菜的桌子加一支笔：本身不做菜，只提供写字和看字的地方。
• ShellShell（外壳——你敲的命令先交给它，由它转达给操作系统内核，好比前台接待）。听着玄，其实就是一个专门"听人话、说机器话"的翻译员。
• 内核 Kernel内核（Kernel，操作系统的核心——真正管硬件、管内存、管文件的那一层）。它好比餐厅后厨：只认标准工单，不接待客人，也不跟客人聊天。
• 提示符 Prompt提示符（Prompt——屏幕上那个 $ 或 > 符号）。简单说，它就是柜台窗口上那块"正在办理"的牌子：牌子亮着，说明现在可以跟它说话。
• REPLREPL（Read-Eval-Print Loop，读取—求值—打印—循环）。换成大白话：你说一句、它办一句、它回一句、再等你下一句，跟医院分诊台一问一答一个节奏。
• 进程 Process进程（Process，正在运行中的程序）。程序装在硬盘里好比菜谱躺在抽屉里；进程是厨师照着菜谱正在炒的那一锅菜——同一份菜谱可以同时炒三锅，那就是三个进程。
• 返回码返回码（Exit Code，退出状态码——命令干完活留下的一个数字，0 代表成功）。打个比方，这就是快递员送完件在系统里点的那一下"已签收"或"客户拒收"：你不一定看得见，但后面的流程全看它。

把这八个词记住，这一节剩下的内容基本就没有黑话了。真的遇到新词，我们会在它第一次出现时立刻用一句人话兜住。

什么是命令行

命令行界面（CLI，Command Line Interface）是一种以纯文本为唯一媒介的人机交互方式。它的运行循环极其简单，只有三步，来回重复：

• 提示符等待屏幕上出现一个 $ 或 >，意思是"我准备好了，请说话"。
• 你敲一行字并回车这一行字就是一条完整的指令，包含你要做的事和所有细节。
• 机器执行并把结果打印成文字成功了通常安静无声，失败了才吐出一段错误。然后提示符再次出现。

这个循环有个专门的名字叫 REPL（Read-Eval-Print Loop，读取—求值—打印—循环）。它像两个人在对讲机上一问一答：你说一句，它答一句，绝不抢话。整个过程没有像素、没有图标、没有动画，输入输出全是字符流。

需要先分清三个经常被混为一谈的东西：终端是那个窗口（负责显示字符、接收键盘），shell 是窗口里跑的那个解释程序（负责读懂你的话），命令是 shell 帮你启动的一个个具体程序。就像：显示器是终端，服务员是 shell，厨师是命令。你冲着显示器喊没用，是服务员在听、厨师在做。

终端、Shell、内核：一家餐厅的三个角色

上面那句话很多人看完就忘，因为三个词长得太像。我们把它彻底展开成一家餐厅，把每个角色的边界画清楚。

为什么非要分这么多层？因为这样才能任意替换。想象一下你在餐厅：换一支笔（换终端软件，比如从系统自带终端换成 Windows Terminal 或 iTerm2），菜还是那些菜；换一个前台接待（把 bash 换成 zsh），说话习惯变了但后厨没变；换一家后厨（换操作系统），前台的话术却大体通用。这种"各层各管一段、互不绑死"的设计，是命令行能活五十年的结构性原因。

再补一个常被问到的细节：终端里跑的第一个程序就是 shell。你打开终端窗口的那一瞬间，它做的事是"启动一个 shell 进程，把窗口的输入输出接到它身上"。所以关掉终端窗口，里面的 shell 也就没了——好比餐厅打烊，前台自然下班。这也解释了一个新手困惑：为什么在终端里跑的任务，一关窗口就断了？因为你把它的"接待"给辞退了。要让任务活下去，就得让它换个不依赖窗口的地方待着（这就是 nohup、tmux 这类工具存在的理由，下一节会碰到）。

shell 是什么：那个"听懂人话"的中间人

shell 这个词字面意思是"外壳"。它包在操作系统内核（kernel）外面，是你和内核之间唯一的翻译官。内核只认系统调用这种极其底层的接口，人类不可能直接手写；shell 的工作就是把你输入的那行人类可读的文字，拆解、展开、翻译成一串系统调用，然后启动进程、等它跑完、把结果送回你眼前。

常见的 shell 有这么几家：

这里有个关键区别值得单独说：bash 系的管道里流的是纯文本，所以下游命令要靠切列、正则去"猜"数据结构；而 PowerShell 的管道里流的是结构化对象，下游可以直接 .Name、.Length 取字段，不用解析文本。这是两套哲学的分野：Unix 相信"文本是万能的通用接口"，微软相信"类型信息不该在管道里丢掉"。两边各有代价，前者简单但脆弱，后者严谨但笨重。

常用命令分类速查：先认门类，再认名字

新手最大的恐慌是"命令有几千个，怎么记得完"。其实不用记完。命令这东西和菜市场的摊位是一个道理：卖菜的、卖肉的、卖调料的、卖干货的，分区固定。你只要知道"要买葱去蔬菜区"，具体哪个摊现问就行。下面这张表就是命令行的"分区图"。

这里要特别推销一下最后那一类。命令行不是没有菜单，它的菜单叫 man（manual，手册）。区别只在于：图形界面的菜单是主动摊在你眼前的，而 man 要你主动去翻。打个比方，图形界面是自助餐台，菜都摆着；命令行是点菜制，菜单要你伸手拿。菜其实一样多，只是取用方式不同。

还有一条极实用的经验：记不住选项就用长选项。rm -r 你三天后会忘，rm --recursive 你一眼就懂。写在脚本里的命令尤其应该用长选项，因为脚本是给未来的自己和同事看的，不是给现在的手指省事的。这一条相当于装修时在配电箱上贴标签：多花十秒，往后省两小时。

命令的三段结构：命令 + 选项 + 参数

几乎所有命令都遵守同一个语法骨架。认清这三段，你就能读懂 90% 的命令，哪怕从没见过那个程序：

ls        -l -a        /home/user
│         │            │
命令      选项         参数
(做什么)  (怎么做)     (对谁做)

• 命令（command）第一个词，就是要运行的程序名。shell 会在 PATH 列出的那些目录里逐个找同名的可执行文件。
• 选项（option / flag）以 - 或 -- 开头，用来调整行为。单字母短选项可以合写：-l -a 等于 -la。长选项更易读：--all。
• 参数（argument）操作的对象，通常是文件名、路径、URL 或一段文字。可以有零个、一个或很多个。

把这三段套到具体例子上，你会发现一切都变得可读：

# 复制：把 a.txt 复制成 b.txt，-v 表示边做边报告
cp -v a.txt b.txt

# 打包：c=create  z=gzip压缩  f=指定文件名
tar -czf backup.tar.gz ./project

# 查找：在当前目录往下找所有 .log 文件，且大于 10MB
find . -name "*.log" -size +10M

# 下载：-O 表示用远端的文件名保存到本地
curl -O https://example.com/data.csv

还有一个隐藏的第四段：返回码（exit code）。命令跑完会悄悄留下一个数字，0 表示成功，非 0 表示各种失败。你平时看不见它，但它是自动化的命脉——脚本正是靠它判断"上一步成了没有，要不要继续"。

管道与重定向：Unix 的组合哲学

如果只讲到上面，命令行只是"用打字代替点击"，没什么了不起。真正让它降维打击图形界面的，是组合能力。

Unix 有一条祖训："写一个只做一件事、并且把它做好的程序；让程序之间通过文本流协作。"于是每个命令都被设计成一个只管一件事的小零件，然后用三种胶水把它们粘起来：

• 管道 |把左边命令的输出，直接当成右边命令的输入。像把两根水管接在一起，数据在中间流动，不落地成文件。
• 输出重定向 > >>把本该打印到屏幕的内容改写进文件。> 是覆盖，>> 是追加。
• 输入重定向 <让命令不从键盘读，而从文件读。省掉手动粘贴的过程。

看一个真实的例子。假设你要从一份几百万行的服务器日志里，找出访问次数最多的前 10 个 IP：

cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

拆开看，这一行其实是六个小工人在流水线上接力：

请认真想一想：如果用图形界面做同一件事，你要怎么做？大概是打开 Excel、导入几百万行文本、按分隔符切列、建数据透视表、排序、截图……十几分钟，而且明天日志更新了得从头再来一遍。而这一行命令，写一次，明天按一下方向键把它调出来，回车，两秒钟出结果。

管道再讲透一点：流水线上的一道工序

上面那一行六段命令，值得再用一个更具体的画面固定下来。管道（Pipe，符号是 |——把左边的输出直接接到右边的输入）干的活儿相当于食品厂的流水线。

想象一下一个洗切菜车间：第一道工位从大筐里往传送带上倒白菜（cat），第二道只把菜叶掐下来、菜根扔掉（awk 取某一列），第三道按大小归堆（sort），第四道把同样大小的捆成一把并写上数量（uniq -c），第五道按数量从多到少重新排（sort -rn），最后一道只取最前面十把装箱（head -10）。

这条流水线的三个特性，恰好就是管道的三个特性：

• 工位之间只认"半成品"第三道工位不需要知道第一道是从筐里倒的还是从车上卸的，它只管接住传送带上过来的东西。换成技术话：命令之间只约定"文本流"这一种接口。这就是所谓的松耦合，说白了就是拆下任何一道工位换成另一台机器，整条线照跑。
• 东西边走边加工，不落地白菜不会先全部堆到地上再进下一道。管道也是边产边消：上游吐一行，下游就能处理一行。所以哪怕日志有 50 GB，管道也不会把 50 GB 全读进内存——这是它能啃超大文件的关键。
• 任一工位卡住，全线等它如果第四道工位手慢，传送带就会堵住。管道也一样：下游处理不过来，上游会被自动按住暂停（术语叫背压）。所以整条命令的速度，由最慢的那一段决定。

顺便认识管道的几个近亲，它们经常一起出现：

特别说一下 2> 里那个 2。每个命令天生有三条通道，术语叫标准输入、标准输出、标准错误，编号分别是 0、1、2。标准输出（编号 1）走的是"正常结果"，标准错误（编号 2）走的是"抱怨和报错"。它们默认都打在同一块屏幕上，所以你以为只有一条路，其实是两条。这个设计好比医院的分诊：普通号和急诊号排两条队，只不过挂号大厅是同一个。分开的好处很实在：你可以把正常结果送进流水线，同时把错误单独存档，两者互不污染。

通配符与正则：一次说清"一批"而不是"一个"

命令行的另一个杠杆，是一句话点一批东西。这靠两套语法，很多人一辈子把它们搞混，其实分界线特别清楚。

通配符（Glob，文件名匹配——由 shell 负责展开的一套简写符号）。它只管一件事：挑文件名。你写 *.log，shell 在把命令交出去之前，先自己去目录里扫一圈，把所有匹配上的文件名一个个铺开写进命令里。听着玄，其实就是你在菜市场说"这一排西红柿我全要"，摊主替你一个个装袋——最后拿到袋子的那个人（也就是那个命令）看到的是十个具体的西红柿，而不是"这一排"这句话。

正则表达式（Regular Expression，正则——一套描述"文字长什么样"的规则语言）。它管的不是文件名，而是文件里的内容，由 grep、sed、awk 这些程序自己解释。简单说：通配符是"点哪几个文件"，正则是"文件里挑哪几行字"。一个在门口筛人，一个进屋后筛话。

注意一个极其常见的坑：* 在这两套语法里意思完全不同。在通配符里 * 自己就代表"任意一串字符"；在正则里 * 是修饰前一个字符的，意思是"前面那个东西重复零次或多次"。所以在正则里想表达"任意一串"，得写 .*。这就好比"红烧"两个字在菜单上和在厨房黑板上写着一样，但一个是菜名一个是做法——同样的字，语境不同含义就变了。

# 通配符：由 shell 展开成一堆文件名
grep "ERROR" *.log

# 正则：由 grep 自己解释，用来筛内容
grep -E "^2024-0[1-3].*ERROR.*timeout" app.log

# 两者同时出现：文件名靠通配符挑，内容靠正则筛
grep -E "[0-9]{3}-[0-9]{4}" contacts/*.csv

环境变量与 PATH：系统找程序的"搜索顺序清单"

环境变量（Environment Variable，环境变量——挂在 shell 身上、所有程序都能读到的一组键值对）。听着玄，其实就是贴在办公室墙上的公告板：不针对某个人，谁进来都能看一眼，照着上面写的规矩办事。

其中最重要的一条公告叫 PATH（可执行文件搜索路径）。它的作用可以用一句话概括：你敲一个命令名，shell 照着 PATH 上的目录顺序一个个去翻，翻到第一个同名的可执行文件就用它，剩下的不再看。

打个比方：这就是图书馆的找书顺序单。你说"给我一本《活着》"，管理员不会把全馆翻遍，而是照着规定顺序去查：先查新书架、再查一楼开架区、再查二楼、最后查库房。哪个架子上先摸到就先拿哪本，后面的同名书压根不看。所以顺序决定了谁生效——这解释了一个经典困惑：明明装了两个版本的 Python，为什么敲 python 出来的总是那个旧的？因为旧的所在的目录在清单上排得更靠前。

# 看看清单本身（Linux/macOS 用冒号分隔）
echo $PATH
# /usr/local/bin:/usr/bin:/bin:/home/me/.local/bin

# 查"这个命令到底用的是哪一个文件"
which python
type -a python      # 把所有同名的都列出来，按优先级排

# 临时把自己的目录插到最前面（只在当前这个窗口有效）
export PATH="$HOME/mytools:$PATH"

注意最后那行的写法：$HOME/mytools:$PATH 是把新目录放在清单最前面，相当于插队；如果写成 $PATH:$HOME/mytools，就是排在最后，只有前面都找不到时才轮到它。插队还是排队末尾，是两个完全不同的效果，改错了会导致"我明明装了新版本，怎么还是老的"。

另外几个你会天天见到的环境变量，一句话各自说清：

• HOME你的家目录，也就是 ~ 指的那个地方。相当于你在公司里的那个工位：默认东西都放这儿。
• PWD当前所在目录。相当于"我现在站在办公楼的哪一层哪个房间"。
• LANG / LC_ALL语言和字符编码设置。它决定报错信息说中文还是英文、中文文件名会不会显示成一堆问号。
• EDITOR默认用哪个编辑器。很多命令（比如 git commit）要你写文字时，就照这个变量决定弹出谁。
• HTTP_PROXY / HTTPS_PROXY代理服务器地址。命令行工具不看系统设置里的代理开关，它们只认这两个变量——这是"浏览器能上网但 curl 不行"的最常见原因。

最后一个要点：环境变量是会"继承"的。shell 启动一个命令时，会把自己身上的变量复印一份交给它；那个命令再启动别的程序，又复印一份传下去。所以它像公司里层层下发的通知：总部发到部门，部门发到小组，小组发到个人。反过来不成立——子进程改了变量，父进程完全不知道。这就是为什么在脚本里 cd 到某个目录，脚本跑完你还站在原地：脚本是另一个人，他挪窝跟你没关系。

相对路径与绝对路径：地址的两种写法

绝对路径（Absolute Path，从根目录写起的完整地址）就像快递单上的完整地址：省、市、区、街道、门牌号，一字不缺。谁拿到这张单子，站在哪儿，都能找到同一个地方。

相对路径（Relative Path，从"当前所在位置"算起的地址）则像口头指路："出门左转，第二个路口右拐，那栋楼三层。"说得对不对，取决于你现在站在哪。同样一句话，换个起点就指向另一个地方了。

什么时候用哪种？给两条硬规矩：手敲操作用相对路径，因为短、快、不容易打错；写进脚本和定时任务一律用绝对路径，因为脚本被别人、被系统、被半夜两点的定时器执行时，"当前目录"完全不是你写代码时那个目录。这条坑坑过无数人：脚本在自己电脑上跑得好好的，扔到服务器上定时执行就报"文件不存在"——问题从来不在文件，在起点。

还有一个必须点出来的细节：./a.txt 里的那个 ./ 平时可以省，但执行程序时不能省。你在当前目录下写了个 deploy.sh，直接敲 deploy.sh 通常会报"命令找不到"，必须写 ./deploy.sh。原因就在上面讲的 PATH：shell 只照清单上的目录找程序，当前目录默认不在清单里。这是一条故意的安全设计——否则有人在某个共享目录里放一个叫 ls 的坏程序，你一进去敲 ls 就中招了。好比图书馆规定"只从正规书架取书，地上捡到的书一律不算馆藏"。

命令历史与快捷键：手不离键盘的那些省时招

命令行的效率有一半不来自命令本身，而来自你不用把同一句话敲第二遍。shell 会把你敲过的每一行都记在一个历史文件里（bash 是 ~/.bash_history），默认存几千条。这相当于餐厅前台记着你的历史订单：你说一句"跟上次一样"，他就能复现。

sudo !! 这一招值得单独说，因为它是命令行里最解气的两个字符。场景是这样：你敲了个命令，回车，屏幕回一句"权限不足"。这时候你不需要把整行重打一遍加个 sudo，只要敲 sudo !!——!! 会被自动替换成刚才那一整行。就像在窗口办事被告知"这个得主管签字"，你不用重新填一张申请单，直接把原单子递给主管即可。

另外强烈建议养成一个习惯：把常用的长命令做成别名（alias，别名——给一串长命令起个短名字）。

# 写进 ~/.bashrc 或 ~/.zshrc，以后每次开窗口都自动生效
alias ll='ls -alh'
alias gs='git status'
alias gl='git log --oneline --graph -20'
alias ..='cd ..'
alias serve='python3 -m http.server 8000'

# 危险操作加一层确认，相当于给删除加个"确定吗"弹窗
alias rm='rm -i'

最后那条 alias rm='rm -i' 是给自己上的保险绳，下面讲坑的时候会解释它为什么重要。

为什么程序员离不开它

不是因为怀旧，也不是为了显得高深。是因为有四件事，图形界面在原理上就做不到。

• 可脚本化命令是文本，文本可以存成文件、可以加 if 和循环、可以被另一个程序生成。你今天手敲的操作，明天就能变成半夜两点自动跑的定时任务。鼠标点击无法被存成文件，也无法被复制粘贴。
• 可远程服务器躺在几千公里外的机房里，没有显示器、没有鼠标。你通过 SSH 连上去，带宽只需要传输几十字节的字符；要是传图形界面画面，那是几十兆的视频流，网络稍差就完全不可用。
• 省资源一个 shell 会话占几 MB 内存，一整套桌面环境要占几百 MB 到几 GB。服务器的每一分内存都该留给业务程序，而不是留给一个没人看的桌面壁纸。
• 可复现这是最被低估的一条。命令可以原封不动地写进文档、贴进工单、发给同事、提交进 Git。"我在设置里点了几下然后就好了"没法复现，也没法追责；docker build -t app:v2 . 谁执行都是同一个结果。

正因如此，整个现代软件工程的地基全是命令行：Git 的每一次提交、CI/CD 流水线的每一步、Docker 镜像的每一层、Kubernetes 的每一次部署——它们的原生形态都是命令，图形界面只是后来贴上去的一层包装。当包装出问题时，你必须能掀开它，直接对底下的命令说话。

# 一个再普通不过的部署脚本：写一次，跑一千次
git pull origin main
npm ci
npm run build
docker build -t myapp:latest .
docker compose up -d
echo "部署完成，返回码 $?"

Windows 上的 CMD、PowerShell、WSL：三家店的区别

Windows 用户一打开"终端"就懵：菜单里怎么有三四个选项？它们的关系，用同一栋楼里三家风格不同的餐厅来说最清楚。

最后一行是新手最容易混淆的地方，值得重复：Windows Terminal 是终端（窗口），不是 shell（翻译官）。它自己不懂任何命令，只负责画字符和开标签页。你在里面选 PowerShell 还是 Ubuntu，才决定了谁来听你说话。这正是本节开头那个"终端和 shell 是两回事"的最好例证。

再补一个最实用的差异对照。同一件事——"列出当前目录里最大的三个文件"——三家店的说法完全不同：

# CMD：能做，但写起来很别扭，基本没人这么干
dir /o-s

# PowerShell：管道里流的是对象，可以直接点字段名取值
Get-ChildItem | Sort-Object Length -Descending | Select-Object -First 3 Name, Length

# WSL / Linux：管道里流的是文本，靠切列和排序
ls -lS | head -4

PowerShell 那行为什么能写 Length？因为它传下去的是一个个"文件对象"，对象上本来就挂着大小、时间、名字这些字段，下游直接取就行。就像菜市场摊主递给你的是一筐贴好标签的菜（品种、重量、产地都写着），你要按重量挑，看标签即可。而 Linux 那行传下去的是一行行文字，下游得自己数"第几列是大小"——相当于摊主递给你一张手写的清单，你得自己从字里认出哪个数字是重量。前者省事但笨重，后者简陋但万能，这就是两套哲学的分野。

新手最容易踩的六个坑

这些坑不是"知识点"，是血泪。每一条都建议现在就记住，因为踩过一次都很疼。

• 坑一：路径里有空格，不加引号你写 cd D:\我的 文档，shell 会把它当成两个参数——一个是 D:\我的，一个是 文档，然后报路径不存在。正确做法是加引号：cd "D:\我的 文档"。原因很朴素：空格是 shell 用来分隔参数的符号，好比餐厅点菜时说"我要 番茄 炒蛋"，服务员听成了两道菜。加引号相当于说"这是一道菜，叫番茄炒蛋"。
• 坑二：rm 没有回收站图形界面里删文件会进回收站，还能翻回来；命令行的 rm 是直接销毁，没有确认、没有回收站、没有 Ctrl+Z。它干的活儿相当于把文件扔进碎纸机，而不是扔进垃圾桶。所以建议给自己加个 alias rm='rm -i'，让它每次删都问一句。更狠的做法是装一个带回收站功能的替代工具。
• 坑三：rm -rf 后面多打一个空格这是命令行最著名的灾难。rm -rf ./build 是删 build 目录；rm -rf . /build（点后面多了个空格）就变成"删掉当前目录的一切，再删 /build"。变量为空时同理危险：rm -rf $DIR/ 里如果 DIR 恰好是空的，这一行就成了 rm -rf /。凡是要写 rm -rf，先用 ls 把同样的路径列一遍，确认删的是你以为的东西再动手。这就像装修工砸墙前先敲一敲确认不是承重墙。
• 坑四：> 会先把文件清空最经典的踩法是 sort a.txt > a.txt，想给文件排序后存回原处。结果是文件变成空的。因为 shell 会先把输出文件清空，然后才开始跑 sort，而 sort 一读，发现文件已经空了。好比你想整理一个抽屉，结果先把抽屉倒空了才开始分类——东西已经没了。正确做法是先写到临时文件再改名。
• 坑五：以为 Ctrl+C 是复制在终端里 Ctrl+C 的历史含义是"中断当前程序"，不是复制。你在终端里跑着一个任务，随手按了它想复制，任务就被掐了。复制通常是 Ctrl+Shift+C，或者直接选中即自动复制（取决于终端软件）。
• 坑六：直接从网页复制命令就回车网页上的命令可能带着看不见的字符（比如全角空格、智能引号），也可能故意藏了一段恶意内容——用 CSS 把危险部分设成不可见，你复制到的其实比看到的多。凡是要 sudo 的命令，先粘到编辑器里看一眼再执行。这一条相当于快递到手先验货再签收，别直接往嘴里放。

把这六条合起来，其实指向同一条底层原则：命令行默认假设"你知道自己在干什么"，它不会替你确认，也不会替你兜底。这种"不啰嗦"是它高效的来源，也是它危险的来源。同一枚硬币的两面，没法只要一面。

CLI 的真实短板

吹完优点，必须诚实地讲缺点。命令行绝不是"更高级"，它只是另一种权衡，代价相当明确：

• 不可发现图形界面把所有能做的事都摆在菜单里，你可以靠"逛"来学习。命令行的屏幕上什么都没有——你不知道自己不知道什么。这是新手最大的痛苦来源。
• 记忆负担重tar -czf 和 tar -xzf 差一个字母，一个是打包一个是解包。选项字母在不同命令里含义还常常不一样，只能靠记和查。
• 容错性差且无撤销图形界面里删文件会进回收站、会弹确认框；命令行里 rm -rf 敲错一个空格，可能直接把系统删了，而且没有 Ctrl+Z。它默认假设"你知道自己在干什么"。
• 不擅长空间信息调色、看图、比对设计稿、拖时间轴剪视频——这些本质上是二维甚至连续量的任务。用文本描述"把这个色块往左移三个像素"是荒谬的，用鼠标一拖就完了。
• 反馈是滞后的你敲完一整行才回车，回车前无法预览效果。图形界面里拖动滑块是实时看到变化的，这种即时反馈对探索性工作极其重要。

所以结论不是"命令行更好"，而是：任务性质决定界面形态。重复、批量、需要精确表达和留痕的工作，交给 CLI；探索性、空间性、一次性的工作，交给 GUI。真正熟练的人两手都会用，并且清楚地知道什么时候该切换到哪一边——这也是下一节 TUI 和第三节 GUI 要继续展开的话题。