2. BusyBox 源码获取与版本选择：Git 仓库、稳定版 vs 开发版、LTS 版本策略
做嵌入式Linux的，没人不知道BusyBox。但你真的会选版本吗？
我见过太多人，上来就git clone最新代码，结果编译出一堆问题。也见过有人死守一个老版本，明明有安全漏洞也不升级。说白了，版本选不对，后面裁剪得再好也是白搭。
2.1 源码从哪里来？
BusyBox的官方仓库在git.busybox.net。我个人习惯直接用git拉取，方便切换分支和打补丁。
# 克隆主线仓库
git clone git://git.busybox.net/busybox.git
# 或者用https（适合公司网络环境）
git clone https://git.busybox.net/busybox.git拉下来之后，你会看到几个关键分支：
- master：开发主线，每天都在变。我一般不直接用这个做产品。
- 1_XX_stable：稳定分支，比如1_36_stable。这是推荐的生产环境选择。
- 标签（tags）：对应正式发布版本，如1.36.0、1.36.1。
2.2 稳定版 vs 开发版：怎么选？
这个问题其实很简单，但很多人纠结。我直接说结论：
| 版本类型 | 适用场景 | 风险等级 |
|---|---|---|
| 稳定版（Stable） | 量产产品、客户交付 | 低 |
| 开发版（Master） | 原型验证、学习研究 | 高 |
| LTS（长期支持） | 工业设备、车机、医疗 | 极低 |
为什么我强调量产用稳定版？
有一次我在项目中图省事，直接用了master分支。功能测试都过了，结果在老化测试时，某个applet的内存泄漏暴露出来。查了半天，发现是master里一个新提交引入的bug。从那以后，我再也不敢在产品里用开发版了。
2.3 LTS版本策略：为什么它很重要？
BusyBox官方没有像Linux内核那样明确的LTS机制，但社区实际上有长期维护的稳定分支。比如1_36_stable，从发布到现在一直在收补丁。
我的建议是：
- 消费类产品：选最新的稳定版，比如1.36.x。生命周期内基本够用。
- 工业/车规产品：选一个稳定分支，锁定版本。比如1_36_stable，只合入安全补丁。
- 航天/医疗：嗯，这种场景我建议你连BusyBox都别用，或者做深度定制审计。
你想想看，一个设备要卖5年，中间BusyBox出了安全漏洞怎么办？如果选了稳定分支，你只需要git pull拉一下补丁就行。如果选了某个tag，就得自己手动backport，那工作量可就大了。
2.4 版本选择的决策流程
我画了一张图，帮你理清思路：
这张图的核心逻辑很简单：先看产品类型，再看生命周期。消费类产品追求新功能，选最新稳定版。工业产品求稳，选稳定分支。生命周期长的，一定要有补丁管理机制。
2.5 版本切换的实用技巧
说几个我在项目中常用的操作：
# 查看所有标签
git tag -l
# 切换到特定稳定分支
git checkout -b my_product_branch origin/1_36_stable
# 查看当前版本
make kernelversion
# 如果需要合入某个补丁
git cherry-pick <commit-id>make defconfig 或 make menuconfig。不同版本的默认配置可能有差异，直接拿旧配置编译新版本，容易出怪问题。
嗯，说到这个我想起来——有一次我图省事，把1.35的.config直接扔到1.36上用。结果编译是过了，但运行时某个applet的行为完全变了。查了两天才发现是新版本改了默认配置。所以，每次换版本，配置一定要重新来过。
2.6 版本选择的终极建议
总结一下我的经验：
- 别追新：BusyBox不是越新越好，稳定才是王道。
- 别守旧：老版本可能有已知漏洞，尤其是CVE列表里挂着的。
- 建立版本基线：产品立项时就把BusyBox版本定下来，后续只合入安全补丁。
- 做好版本记录：在代码仓库里用README或CHANGELOG记录BusyBox版本和修改内容。别问我为什么强调这个——我曾经在一个项目里翻遍了git log都找不到BusyBox版本号，那种感觉，你懂的。
版本选好了，裁剪就成功了一半。下一节我们聊聊配置裁剪的具体操作，那才是真正考验功力的时候。