4. 配置系统详解：默认配置、自定义配置、静态编译与动态编译的选择
配置 Busybox，说白了就是告诉它：「你要支持哪些命令，怎么编译，跑在什么环境里。」
我刚开始接触 Busybox 时，觉得配置这一步挺简单的——不就是 make menuconfig 嘛。后来在项目里栽了几次跟头，才明白这里面的门道有多深。今天咱们就把配置系统彻底聊透。
4.1 默认配置：快速上手的捷径
Busybox 自带了几套默认配置，适合不同场景。我个人最常用的是这两套：
| 配置类型 | 命令 | 适用场景 |
|---|---|---|
| defconfig | make defconfig |
通用嵌入式环境，启用大部分常用命令 |
| allyesconfig | make allyesconfig |
测试/验证，启用所有功能（体积巨大） |
| allnoconfig | make allnoconfig |
最小化系统，只保留核心功能 |
make defconfig 打底，再按需裁剪。这样既不会漏掉关键功能，也不会一开始就陷入配置细节。
执行 make defconfig 后，Busybox 会在源码根目录生成 .config 文件。这个文件就是所有配置的「总开关」，每一行都是一个配置项。
# 查看 .config 文件片段
$ head -20 .config
#
# Automatically generated make config: don't edit
# Busybox version: 1.36.0
#
CONFIG_HAVE_DOT_CONFIG=y
#
# Busybox Settings
#
CONFIG_BUSYBOX=y
CONFIG_FEATURE_SH_IS_ASH=y
CONFIG_FEATURE_SH_IS_HUSH=n
CONFIG_FEATURE_SH_IS_MSH=n
嗯，这里要注意：永远不要手动编辑 .config 文件。我见过有人直接改这个文件，结果格式不对，编译报错折腾了半天。正确的做法是用配置工具。
4.2 自定义配置：用 menuconfig 精雕细琢
make menuconfig 是基于 ncurses 的图形化配置界面。它把配置项分门别类，操作起来很直观。
核心操作：
- Y — 启用该功能（编译进 Busybox）
- N — 禁用该功能
- M — 编译为模块（Busybox 中较少使用）
- Space — 循环切换 Y/N/M
- /? — 查看帮助和依赖关系
配置项之间是有依赖关系的。比如你启用了 CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE，它依赖 CONFIG_TOP 必须先启用。menuconfig 会自动处理这些依赖，这也是我推荐用它而不是手动改文件的原因。
CONFIG_FEATURE_SUID 关了。结果编译出来的 ping 命令没有权限创建原始套接字，根本用不了。后来查文档才发现，ping 依赖 SUID 权限才能正常工作。所以配置时一定要看依赖关系，别盲目裁剪。
4.3 静态编译 vs 动态编译：一个影响深远的决定
这是配置系统里最重要的一个选择。它直接决定了你生成的 Busybox 二进制文件怎么跑起来。
| 对比维度 | 静态编译 (STATIC) | 动态编译 (SHARED) |
|---|---|---|
| 配置项 | CONFIG_STATIC=y |
CONFIG_STATIC=n |
| 文件大小 | 较大（约 800KB-1.2MB） | 较小（约 200KB-400KB） |
| 运行时依赖 | 无，独立运行 | 依赖 libc.so 等动态库 |
| 启动速度 | 稍快（省去动态链接过程） | 稍慢（需要加载动态库） |
| 升级维护 | 需重新编译整个 Busybox | 可单独升级动态库 |
| 适用场景 | initramfs、单板系统、救援环境 | 完整文件系统、有动态库的环境 |
你想想看，如果你的系统只有 4MB 的 Flash，用动态编译能省出几百 KB 空间，这很诱人。但代价是必须保证 libc 等动态库存在且版本兼容。
4.4 配置系统的核心逻辑：一张图看懂
下面这张图展示了 Busybox 配置系统的完整工作流程。从你执行 make menuconfig 开始，到最终生成二进制文件，每一步都环环相扣。
4.5 实战：如何做出正确选择
说了这么多理论，咱们来点实际的。假设你现在要为一个 8MB Flash 的 ARM 设备构建 Busybox，你会怎么选？
- 先评估空间： 8MB Flash，内核占 2MB，文件系统占 4MB，还剩 2MB。动态编译的 Busybox 约 300KB，加上 libc（约 1MB），总共 1.3MB。静态编译的 Busybox 约 900KB，省去了 libc 的 1MB，反而更省空间。
- 再考虑维护： 如果产品生命周期长，后期可能升级 libc 修复安全漏洞，动态编译更方便。如果是一次性部署，静态编译更省心。
- 最后做决定： 我个人在这种场景下会选静态编译。原因很简单——少一个依赖，少一个故障点。而且 900KB 比 1.3MB 还省了 400KB 空间。
配置命令速查：
# 静态编译
make menuconfig
# 进入 Settings → Build static binary (no shared libs) → 按 Y 启用
# 或者直接修改 .config（不推荐）
sed -i 's/CONFIG_STATIC=n/CONFIG_STATIC=y/' .config
# 验证配置
grep CONFIG_STATIC .config