2、开发环境搭建：搭建Ubuntu编译环境、配置Windows开发工具链、获取源码与版本管理
2.1 为什么我坚持用Ubuntu做编译环境
说实话，鸿蒙系统的编译环境，我踩过不少坑。
一开始我也试过在Windows上直接编译，但折腾了两天，各种依赖冲突、路径问题、权限报错，搞得我头大。后来我学乖了——老老实实上Ubuntu。我个人习惯用 Ubuntu 20.04 LTS，这个版本稳定，社区支持好，鸿蒙官方也推荐。
你可能会问：「用虚拟机行不行？」当然可以。我在项目中就经常用VMware或VirtualBox跑Ubuntu。但有一点要注意：磁盘空间至少留80GB，内存给8GB以上。鸿蒙源码拉下来加上编译产物，轻松吃掉30-40GB。我第一次编译时只给了40GB磁盘，结果编译到一半报磁盘满，那叫一个尴尬。
核心要点：Ubuntu 20.04 LTS + 80GB磁盘 + 8GB内存，这是最低配置。别省这点资源，后面编译失败更浪费时间。
2.2 搭建Ubuntu编译环境，一步步来
嗯，这里要注意，环境搭建的顺序很重要。我建议按这个步骤来：
- 更新软件源：
sudo apt update && sudo apt upgrade -y - 安装基础工具：gcc、g++、make、cmake、git、curl、wget
- 安装Python环境：鸿蒙编译脚本依赖Python 3.8+，我一般装3.9
- 安装Node.js和npm：部分工具链需要
- 安装repo工具：这是管理鸿蒙多仓库的关键
具体命令我贴出来，你直接复制执行就行：
# 基础工具
sudo apt install -y gcc g++ make cmake git curl wget
# Python 3.9
sudo apt install -y python3.9 python3.9-dev python3-pip
# Node.js 14+
curl -fsSL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt install -y nodejs
# repo工具
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
echo 'export PATH=~/bin:$PATH' >> ~/.bashrc
source ~/.bashrc我的小技巧：装完Python后，记得把pip源换成国内镜像。不然下载依赖包能慢到你怀疑人生。我一般用清华源：pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple
2.3 配置Windows开发工具链
你可能会问：「不是用Ubuntu编译吗？Windows拿来干嘛？」
说白了，Windows是你的日常开发环境。写代码、看文档、烧录调试，这些还是在Windows上顺手。我个人的工作流是：Windows上写代码，推送到Git服务器，Ubuntu上拉下来编译。
Windows上需要装这些：
| 工具 | 用途 | 推荐版本 |
|---|---|---|
| VS Code | 代码编辑器 | 最新稳定版 |
| Git for Windows | 版本管理 | 2.30+ |
| PuTTY / MobaXterm | SSH连接Ubuntu | 最新版 |
| 华为HiBurn / DevEco | 烧录调试 | 根据芯片型号选 |
| USB驱动 | 识别开发板 | 板厂提供 |
我记得有一次，我折腾了一下午，发现开发板连不上电脑。最后发现是USB驱动没装对。嗯，这种低级错误，犯过一次就不会再犯了。
避坑指南：Windows路径中不要有中文和空格！鸿蒙的编译脚本对路径很敏感。我曾经因为用户名是中文，导致编译脚本找不到文件，排查了整整两个小时。后来我直接在C盘根目录建了一个ohos文件夹，所有工作都在里面做。
2.4 获取源码与版本管理
源码获取，说白了就是拉代码。鸿蒙的源码托管在多个Git仓库里，用repo工具统一管理。
我个人建议，第一次拉代码时，不要拉全量。鸿蒙全量源码大概有10GB+，网络不好的话能拉一整天。你可以先拉一个小型系统版本，比如针对Hi3861的轻量系统，只有几百MB。
具体操作：
# 创建工作目录
mkdir ~/ohos && cd ~/ohos
# 初始化repo（以OpenHarmony 3.1 Release为例）
repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-3.1-Release --no-repo-verify
# 同步源码（只同步master分支，减少数据量）
repo sync -c --no-tags -j4这里解释一下参数：
-c：只同步当前分支，不同步其他分支的历史--no-tags：不同步标签信息，省流量-j4：4个线程并行下载，网络好可以调大
我的经验：如果网络不稳定，repo sync容易中断。我一般会在命令外面套一个循环：while true; do repo sync -c --no-tags -j4; if [ $? -eq 0 ]; then break; fi; sleep 5; done。这样断了会自动重试，省得你一直盯着。
2.5 版本管理，别小看这个
你想想看，鸿蒙版本迭代这么快，今天拉的是3.1，明天可能就出3.2了。如果你不做好版本管理，后面出了问题都不知道该找谁。
我个人的做法是：
- 用分支管理：每个项目建一个独立分支，不要直接在master上改
- 打标签：每次编译成功，打个tag，比如
v1.0_hi3861_ok - 记录编译配置：把编译命令、环境变量、补丁文件都记下来，放在项目根目录的
BUILD_NOTES.md里
我曾经接手过一个项目，前任工程师离职了，源码目录里一堆未命名的文件夹，编译脚本也不知道用的是哪个版本。我花了整整一周才把环境复现出来。从那以后，我养成了「每步都记录」的习惯。
总结一下：环境搭建这件事，看起来琐碎，但决定了你后面所有工作的效率。花半天时间把环境搭好、把版本管好，后面能省下无数个半天。别急，慢慢来，比较快。
好了，环境搭好了，下一章我们开始真正的裁剪与定制化移植。到时候我会拿一块具体的开发板，手把手带你走一遍流程。