4. 静态编译 vs 动态编译：两种方式的优劣分析，以及如何选择
说实话，这个问题几乎每个做嵌入式Linux的人都会遇到。我记得刚入行那会儿，第一次用Busybox做根文件系统，图省事直接用了动态编译。结果板子一启动，控制台疯狂报错——"can't load library"。当时我就懵了，明明在宿主机上跑得好好的啊。
后来才明白，静态编译和动态编译，本质上是在空间和灵活性之间做取舍。没有绝对的好坏，关键看你的场景。
4.1 两种方式的核心区别
先看一张图，把整体逻辑理清楚：
4.2 静态编译：一把梭的痛快
静态编译，说白了就是把所有用到的库函数直接塞进可执行文件里。你编译出来的Busybox，就是一个独立的、完整的二进制文件。
核心优势： 部署极其简单。只要把这一个文件扔到板子上，就能跑。不需要考虑目标板上有没有libc、有没有其他依赖库。
我在项目中遇到过最典型的场景——给一个只有2MB Flash的MCU级Linux设备做根文件系统。那板子连glibc都装不下，更别提什么ldconfig了。怎么办？静态编译Busybox，一个文件搞定所有命令。
编译命令也很直接：
make menuconfig
# 进入 Settings → Build Options
# 选中 "Build BusyBox as a static binary (no shared libs)"
make -j4编译完看看大小：
$ ls -lh busybox
-rwxr-xr-x 1 root root 1.2M Apr 10 10:30 busybox1.2MB，一个文件，包含了ls、cp、mv、sh等上百个命令。你想想看，这部署起来多省心。
4.3 动态编译：精打细算的选择
动态编译就不一样了。Busybox本身很小，但运行时需要加载外部的共享库（主要是libc.so）。
编译方式：
make menuconfig
# 取消选中 "Build BusyBox as a static binary"
make -j4看看文件大小：
$ ls -lh busybox
-rwxr-xr-x 1 root root 360K Apr 10 10:35 busybox360KB，比静态版本小了将近1MB。但别高兴太早——你得把libc.so也拷到板子上。
我的建议： 如果板子上已经有完整的文件系统（比如基于buildroot或Yocto构建的），动态编译是更好的选择。因为libc已经在系统里了，Busybox只需要引用它。
4.4 两种方式的详细对比
我把关键差异整理成了一张表，方便你对照：
| 对比维度 | 静态编译 | 动态编译 |
|---|---|---|
| 可执行文件大小 | 较大（约1~2MB） | 较小（约300~500KB） |
| 运行时依赖 | 无外部依赖 | 依赖libc.so等共享库 |
| 部署复杂度 | 低，单文件拷贝 | 高，需同步部署库文件 |
| 内存占用 | 每个进程独立加载库代码 | 多进程共享库代码（节省内存） |
| 库版本升级 | 需重新编译Busybox | 只需替换.so文件 |
| 调试便利性 | 较难，库代码已内嵌 | 较易，可单独调试库 |
| 安全更新 | 需整体替换二进制 | 可单独更新libc |
4.5 如何选择？我的实战经验
这个问题没有标准答案，但我可以给你几个判断依据：
场景一：最小系统 / 急救系统
如果你在做initramfs、或者给一个只有kernel+Busybox的最小系统，选静态编译。我曾经给一个NAND Flash坏块的板子做紧急恢复，根文件系统就一个静态编译的Busybox，外加几个脚本。启动后直接挂载网络文件系统，完美避开坏块问题。
场景二：完整文件系统
如果板子上已经有完整的Linux发行版（比如Debian for ARM、或者自己用buildroot做的系统），选动态编译。因为libc已经在系统里了，动态编译能省下不少Flash空间。而且后续升级libc安全补丁时，不需要重新编译Busybox。
场景三：空间极度受限
Flash只有4MB甚至更少？选动态编译，但要注意——你得确保libc的版本和Busybox编译时用的版本一致。我踩过这个坑：宿主机是glibc 2.31，板子上是glibc 2.28，结果Busybox启动时报"FATAL: kernel too old"。嗯，版本不匹配的问题很隐蔽。
我曾经踩过的坑： 动态编译的Busybox在板子上跑不起来，提示"can't load library"。排查了半天，发现是板子上的/lib目录下缺少ld-linux.so.3这个动态链接器。记住，动态编译不仅需要libc.so，还需要ld-linux.so这个"引导加载器"。
4.6 一个实用的混合策略
其实，你不必非此即彼。我个人习惯的做法是：
- 核心命令静态编译：比如init、sh、mount、insmod这些系统启动时必须用的命令，静态编译确保万无一失。
- 其他命令动态编译：像ls、cp、cat这些用户态命令，动态编译节省空间。
怎么做？Busybox支持按命令单独配置编译方式：
make menuconfig
# 进入每个命令的详细配置
# 例如：Coreutils → ls
# 可以单独设置 "Build as static binary (no shared libs)"这样既能保证系统启动阶段的可靠性，又能节省整体空间。我在一个8MB Flash的项目里用过这个方案，效果很好。
4.7 验证你的选择
不管选哪种方式，编译完后一定要验证：
# 查看动态链接依赖
$ readelf -d busybox | grep NEEDED
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
# 如果是静态编译，应该没有NEEDED条目
$ readelf -d busybox | grep NEEDED
# 输出为空另外，我建议你在目标板上用strace跑一下Busybox，看看它实际打开了哪些库文件：
# strace -e openat busybox ls 2>&1 | grep "\.so"这样能确认运行时依赖是否都到位了。
嗯，静态编译和动态编译的选择，说到底就是空间换灵活还是灵活换空间的问题。没有银弹，但理解了背后的原理，你就能根据实际场景做出合理判断。