从 0 到 1：用 Windows 写代码，Linux 编译运行，一步到位

一、图中分工逻辑

二、为什么要这么分？而不是全在 Windows 搞定

很多新手会问：“我用 Windows 的 Dev-C++/MinGW 也能写 C、编译、运行，为什么还要折腾 Ubuntu 虚拟机？”

核心原因有 3 个：

1. 开发链的一致性你后续做嵌入式开发（比如 STM32、Linux 驱动），目标平台大多是 Linux 环境，提前在 Ubuntu 上熟悉gcc编译、Makefile、命令行操作，能避免后期环境不兼容的大坑。
2. 工具链的原生支持gcc是 Linux 的原生编译器，Windows 上的 MinGW 是 “模拟环境”，遇到复杂项目（比如多文件编译、链接库）时，很容易出现链接错误、路径问题，Ubuntu 上直接用gcc更稳定。
3. 多文件 / 项目管理更方便后续写多个.c文件、用Makefile管理工程时，Ubuntu 的命令行工具（ls、cd、make）比 Windows 的图形界面高效得多，也更符合工业界的开发习惯。

三、这套流程的关键细节（图里的命令拆解）

1. 编译命令的两种写法

# 方式1：默认生成a.out（不推荐，文件名不直观） gcc 1-Helloworld.c # 方式2：指定生成的可执行文件名hello（推荐，方便区分） gcc 1-Helloworld.c -o hello

-o参数的作用就是指定输出文件的名字，避免一堆项目里全是a.out分不清哪个是哪个。

2. 运行命令的两种形式

# 方式1：相对路径（当前目录下的可执行文件，最常用） ./hello # 方式2：绝对路径（全路径直接执行，适合不在当前目录时用） /mnt/hgfs/CS2618/1-C语言/1-环境安装/2-code/hello

./表示 “当前目录”，因为 Linux 默认不会把当前目录加入环境变量，所以必须用./告诉系统 “我要执行当前目录下的这个文件”。

四、进阶优化建议

随着代码量增多、项目复杂度提升，推荐做几项优化，规避问题同时养成专业开发习惯。

1. 优化文件存放：分清共享目录与本地目录 我们当前使用的 /mnt/hgfs，是 VMware 虚拟机共享文件夹的默认挂载路径。

Windows 和 Ubuntu 是两个独立系统，文件默认无法互通。

开启虚拟机共享文件夹功能后，Windows 中的共享目录会自动映射到 Ubuntu 的 /mnt/hgfs：

• mnt：Linux 系统专门用来挂载外接设备、共享文件的目录；
• hgfs：VMware 固定命名，属于软件预设路径，不能随意修改。

该方式仅适合临时练习，项目变大后，容易出现权限报错、文件同步延迟、读写卡顿等问题，因此推荐改用Ubuntu 本地目录存放代码。

在 Linux 终端里，~ 是当前用户家目录的简写，和共享文件夹没有任何关联。

~/projects/c-demo 等价于完整路径 /home/你的用户名/projects/c-demo，目录完全存放在 Ubuntu 虚拟机本地，运行更稳定。

操作步骤：

1. 终端执行命令，创建本地项目文件夹：

mkdir -p ~/projects/c-demo

后续所有代码都存放至此，彻底摆脱共享文件夹的各类隐患。

2. VSCode 安装 Remote-SSH 插件，远程连接 Ubuntu 直接编写代码，编码、编译、运行全程在 Linux 环境完成，贴合行业真实开发流程。

2. 巧用虚拟机快照备份环境 Ubuntu 环境配置完成后，建议给虚拟机创建快照。

后续若因误操作导致环境出错、软件异常，直接恢复快照就能回到正常状态，无需重新装机配置。

五、拓展：嵌入式领域主流多系统分工方案

除了本文「Windows 编辑 + Linux 编译运行」的入门模式，实际嵌入式项目中有一套更成熟的分工体系：

• Windows：运行 Keil、STM32CubeMX 等工具，完成工程配置、硬件调试、波形查看等工作；
• Ubuntu：负责代码编译与工程构建，使用 arm-none-eabi-gcc 交叉编译器，生成嵌入式设备专用固件；
• 硬件开发板：作为最终运行平台，烧录固件后完成程序实测与验证。 本文讲解的开发流程，正是学习嵌入式开发必须掌握的基础。