从 vi 到运行：Linux 下 C 语言开发的标准五步曲

        在图形化 IDE（如 VS Code、CLion）大行其道的今天，为什么我们仍然要学习在 Linux 终端里用 vi 写代码、用 gcc 编译？

        因为这是理解“程序是如何诞生”的最短路径。没有智能提示，没有一键构建，每一个步骤都赤裸裸地暴露在你面前。这种“笨拙”，恰恰是建立底层认知的最佳方式。

        今天，我们就以一张经典的 Linux 操作截图为线索，完整拆解 编写 → 确认 → 编译 → 验证 → 运行 这五个标准步骤，并附赠一份让你不再害怕 vi 的生存指南。

🔍 五步流程深度解析

1. vi Sum.c —— 与编辑器对话

        这不是简单的“打开文件”。在 Linux 哲学中，vi 是一个模式化编辑器：

• 命令模式（默认）：你敲下的每个键都是指令（删除、复制、跳转），而不是字符输入。
• 插入模式（按 i 进入）：此时才真正开始打字写代码。
• 底行模式（按 : 进入）：执行保存、退出、搜索等高级命令。

⚠️ 新手第一坑：打开 vi 后直接敲键盘发现“打不出字”或“乱跳”？因为你还在命令模式。记住：先按 i，再写字。

        如果 Sum.c 不存在，vi 会创建一个空缓冲区；如果已存在，则加载原文件内容。这一步完成了源码的物理创建。

2. ls —— 第一次确认

        写完代码、:wq 保存退出后，为什么要立刻 ls？

• 确认文件落盘：防止因误操作（如忘记保存、路径错误）导致代码丢失。
• 检查文件名：Linux 区分大小写，sum.c 和 Sum.c 是两个完全不同的文件。
• 养成习惯：在命令行世界里，“信任但要验证”是黄金法则。

3. gcc Sum.c -o Sum —— 从文本到机器码

        这是整个流程的核心魔法时刻。gcc 做了四件事（虽然一条命令搞定，但内部经历了四个阶段）：

   -o Sum 指定了输出文件名。如果不加 -o，默认生成 a.out——一个毫无语义的名字。永远显式指定输出名，这是工程素养的起点。

4. ls（第二次）—— 验证编译产物

        这次 ls 的目的不同于第一次：

• 看颜色：在大多数 Linux 发行版中，可执行文件显示为绿色。看到绿色的 Sum，说明编译成功且具备执行权限。
• 看时间戳：确认文件是刚刚生成的，而非上次残留的旧版本。
• 排错信号：如果 Sum 没出现，立刻回看 gcc 的输出信息，定位编译错误。

5. ./Sum —— 见证结果

        注意前缀 ./ 的含义：在当前目录下查找可执行文件。

• 为什么不能直接输 Sum？因为出于安全考虑，当前目录 . 默认不在 $PATH 环境变量中。系统不会自动在当前目录搜索可执行程序，防止恶意脚本被意外执行。
• 程序运行后，输入 1 2，输出 sum = 3。至此，从人类可读的 C 源码到机器执行的二进制程序，完成了一个完整的生命周期。

🎯 Vi 新手必背快捷键清单

   vi/vim 的学习曲线陡峭，但掌握以下 20% 的命令即可覆盖 80% 的日常编辑场景：

模式切换（最重要！）

• i → 进入插入模式（开始写字）
• Esc → 返回命令模式（停止写字，准备发指令）
• : → 进入底行模式（保存/退出/搜索）

保存与退出

• :wq → 保存并退出
• :q! → 强制退出不保存（改坏了想放弃时用）
• :w → 仅保存不退出

移动与编辑

• h j k l → 左下上右（替代方向键，手不离主键区）
• dd → 删除当前行
• yy → 复制当前行
• p → 粘贴到光标下方
• /关键词 → 向下搜索，n 找下一个
• u → 撤销上一步操作

💡 肌肉记忆训练法：不要试图一次记住所有命令。先用上面这份清单完成 3-5 次完整的“编辑-保存-编译”循环，遇到新需求时再查表补充。vi 不是背出来的，是用出来的。

📌 写在最后

        这张截图记录的不仅是一次 C 程序的编译运行，更是 Unix 哲学的具象化：

• 工具单一职责：vi 只管编辑，gcc 只管编译，ls 只管列出文件。每个工具做好一件事，通过命令行管道组合。
• 文本即接口：源代码是文本，配置是文本，连编译器的错误信息也是文本。一切皆可被 grep、sed、awk 处理。
• 显式优于隐式：没有自动保存，没有后台编译，每一步都需要你明确下达指令并承担后果。

        当你熟练走过这五步之后，再回到 IDE 中，你会发现自己对“构建”、“调试”、“部署”的理解，已经比只会点按钮的人深了一个维度。