BusyBox 体积优化策略从源码到 200KB 的秘密

为什么 BusyBox 这么小

BusyBox 的小体积不是偶然，是从设计之初就贯穿每一行代码的目标。它使用了一系列编译期和运行期的技术手段：

静态编译：默认编译方式。所有依赖直接嵌入二进制，不加载动态库。这样做的好处是单文件就能运行，不需要目标系统有 glibc；代价是体积稍大（约增加 10-20%），但换来的是部署极其简单。

musl libc 优先：BusyBox 官方提供 musl 链接的预编译版本。musl libc 本身比 glibc 小得多，静态编译 BusyBox 时首选 musl 而不是 glibc。defconfig 下 musl 链接约 1.1MB，glibc 链接约 1.3MB。

LTO（链接时优化）：CONFIG_LTO=y 开启 GCC/Clang 的链接时优化，编译器可以跨文件内联和死代码消除，通常能再减 5-15%。

strip：编译完成后必须 strip，去掉调试符号和冗余段。这个动作能砍去 30-50% 的体积。

按 Applet 开关：make menuconfig 里每个工具一个独立选项，你可以精确到 ls 开、cat 关。这是最直接的体积控制手段。一个极致裁剪的 BusyBox 只启用必要工具，可以做到 200KB 左右。

按功能开关：每个 Applet 内部也有子选项。比如 ls 可以开/关颜色支持、长选项、--time-style 等。关掉冷门选项能再省几 KB。

config 压缩：BusyBox 的 .config 文件支持自动按依赖关系关闭未使用选项，make allyesconfig 全开后再手动或脚本化裁剪。

极简代码风格：BusyBox 的编码规范明确要求函数尽量短、变量尽量少、避免不必要的抽象。很多工具的实现只有几十行代码，功能上够用但绝不追求优雅。

错误处理简化：GNU 工具的错误信息极其详细，BusyBox 通常只打印一行简短提示。省下来的字符串空间积少成多。

共享通用组件：很多工具内部共用代码——比如 cp 和 mv 都调用同一个文件复制函数，而不是各自实现一套。

不同配置下 BusyBox 的静态编译体积大致如下（musl libc）：

注意：动态链接（使用目标系统的 libc）的 BusyBox 静态部分更小，但依赖完整的 libc.so，总磁盘占用不一定更低——嵌入式系统往往需要额外部署 libc。

从零开始裁剪 BusyBox 时，推荐的起点是 defconfig，然后逐步关闭确认不需要的 Applet。如果从 allnoconfig（全部关闭）开始手动开启，很容易遗漏依赖。裁剪完成后务必实际运行一遍目标场景的脚本——某些看似没用的工具可能被依赖链间接调用。