前言

随着总结的文章越写越多，我发现自己是一个“追求完美”的人，但同时也是一个“虎头蛇尾”的人，这两者看起来冲突，却可以融于一身。去写一个问题是总想从三皇五帝时写起，总想把各个分支情况都写清楚，这就会创造一个“虎头”，但写着写着就发现时间不允许了，或者已经触及了自己的知识边界，最后不得不退化成了“蛇尾”。

这对于总结和传播知识是不合适的，对于知识的总结应该做到详略得当，这一点上我还有很大的提升空间，推荐一本这方面做的比较好的书籍《图解HTTP》，这本书从始至终让人感觉到很丰满，没有哪一部分让人感觉是凑数的，特别的讲到电信号在同轴电缆中的传播，给人一种知识体系非常完整的体验。

言归正传，今天我要谈谈图形用户界面和命令行的区别，工作久了以后总会有点自己的心得，灵光一闪时就想记录下来，算是给今后的自己保存一点点瞬时的记忆，今天就不从三皇五帝开始讲了，我们从计算机的诞生开始说起。

世界世界上第一台电子计算机 ENIAC，是一个占地170平方米，重达30吨的庞然大物，慢慢的计算机的体积越来越小，但主要用于特定领域，并未进入寻常人家，此阶段的计算机多用于完成特定任务，也就是输入指令完成任务，我们看到的更多的是黑框框，后来随着windows系统（当然苹果系统也出现了）的普及，鼠标点点点极大的降低了入门的难度，也使得图形用于界面深入人心。

关于Windows内置的四款游戏据说每一款都有其特殊的目的与作用，纸牌希望让用户熟悉拖动和释放鼠标；扫雷是为了训练用户使用鼠标进行精准的点击，并掌握左键与右键的区别；红心大战是为了鼓励用户使用互联网与其他玩家交流；空当接龙是为了测试32位的数据处理子系统是否正确安装。这些游戏的出现让人们快速适应了图形用户界面，甚至这是他们接触电脑的第一印象，可能他们并不懂得什么是命令行。

对比

图形用户界面和命令行不能说哪一种更好，只能说哪一种更合适，一些情况下图形界面会给你更直观的感受，一些情况下命令行可以代替重复性的操作。

图形用户界面

图形用户界面，简称GUI，现在绝大多数的用户面对的都是图形界面，而传统意义上的命令行总被看成是上世纪的东西，图形界面首先看起来很直观，就像给你一堆散列的数据很难看出关系，但是如果画一个折线图，立马就能看出数据的走向。

命令行

它的门槛要高一些，虽然使用起来不如图形界面清晰，但是在一些自动化程序中，命令行可以简化操作，省去了点点点的麻烦操作

举个例子

我们以git为例，他在被Linus发明出来的时候肯定只有命令行，但是后来git的图形界面工具多到数不清，一个又一个方便的软件被创造出来，但是git命令行一直没有消失，而且我每天都在用，是因为我不会用图形界面吗？当然不是，因为在我使用的大部分需求中，我只要敲一两个命令就可以完成了，不必拿起鼠标右键菜单再去等几秒中的界面刷新。

还有一方面我需要经常编写自动化脚本，使用Jenkins部署服务器程序，这些环境下是没办法使用图形界面的，只能用命令行还编写逻辑。

适用场景

图形界面

适用于需要直观显示的情景，以及需要根据显示结果反复调整输入的情景，比如过滤commit，我可以在界面上不断调整和尝试过滤的关键词，而结果会随着我的调整发生改变。

命令行

适用于简单命令和机械化的操作，最好是那种写完一遍可以用一辈子的逻辑，如果是类似过滤commit这种需求，我们必须不断的重新输入命令参数，也就是说命令行在我输入命令之后他的参数都确定了，绝大多数不能再调节了。

总有例外

命令行的参数输入之后真的不能调吗？大多数是这样的，但总有例外，这种例外要求命令结果处于定时刷新状态，比如 top 命令，因为它的结果是可以刷新的，所以当你按下键盘上的 c 、P 等按键时，输出结果是会发生变化的。

总结

• 图形界面和命令行两者没有更好，只有更合适
• 图形界面适用于直观显示需求，可以根据用户输入随时调整输出结果
• 命令行更适用于自动化场景，可以将指令编写到操作逻辑中，通常来说更加高效

发现了一种我称之为反围城的状态：外面的人不想进去，里面的人不想出来~