核心Applets选择策略：文件系统工具、Shell工具、文本处理工具的取舍
说实话，很多刚接触BusyBox裁剪的朋友，最容易犯的错就是——全选。
我见过有人把BusyBox所有Applets都编译进去，结果镜像大了好几兆。对于嵌入式设备来说，每一KB的Flash空间都很珍贵。你想想看，一个只有4MB Flash的路由器，你光BusyBox就占了2MB，那应用层还怎么玩？
所以今天咱们聊聊核心Applets的选择策略。我重点讲三类：文件系统工具、Shell工具、文本处理工具。这三类几乎每个嵌入式系统都会用到，但怎么取舍，里面门道不少。
核心原则：只选你真正需要的。不要因为「可能以后会用」就一股脑全加上。嵌入式系统讲究的是「够用就好」。
文件系统工具：ls、cp、mv 的取舍
文件系统工具是基础中的基础。我个人习惯，ls、cp、mv、rm、mkdir 这五个是必选的。为什么？因为启动脚本、应用升级、日志管理都离不开它们。
但有些工具就要看情况了。比如：
- dd：如果你需要做裸设备读写、磁盘克隆，那就选上。我做过一个工业控制项目，需要从NAND Flash的特定偏移地址读取校准数据，dd 就派上了大用场。但如果只是普通文件操作，完全可以不选。
- find：这个工具挺占空间的。如果你的文件系统结构简单，目录层级不超过3层，那完全可以用 shell 的 for 循环替代。我曾经在一个项目里为了省 8KB 空间，硬是把 find 去掉了，改用
for f in /path/*; do ... done，效果一样。 - tar：如果你有固件升级功能，tar 几乎是必选的。但如果你用的是压缩率更高的 squashfs 或 jffs2 文件系统，那 tar 就可以省了。
- chmod、chown：如果你的系统有用户权限管理，这两个必须选。但很多嵌入式设备是单用户系统，甚至没有 /etc/passwd 文件，那 chown 就是多余的。
我的经验：先列一个清单，把启动脚本、应用层代码、调试接口中实际用到的命令全部列出来。然后对照 BusyBox 的 Applets 列表，只选这些。别靠猜，靠跑。
Shell工具：sh 与 ash 的选择
Shell 是嵌入式系统的灵魂。没有 Shell，你的系统就是个黑盒子。
BusyBox 提供了多种 Shell：ash、hush、msh、sh（其实是 ash 的别名）。我强烈建议：选 ash。
为什么？
- ash 是 BusyBox 默认的 Shell，兼容 POSIX 标准，功能完整。支持变量、循环、条件判断、函数。启动脚本完全够用。
- hush 更小，但功能受限。不支持数组、不支持某些重定向语法。我试过一次，结果一个复杂的启动脚本跑不起来，排查了半天才发现是 hush 的 bug。后来再也不敢用了。
- msh 是 Minix Shell，非常古老，语法怪异。除非你是在维护古董级系统，否则别碰。
那 sh 呢？在 BusyBox 里，sh 其实就是 ash 的符号链接。所以你选了 ash，sh 自然就有了。
注意：如果你选了 ash，记得把 CONFIG_ASH 相关的选项都打开。特别是 CONFIG_ASH_JOB_CONTROL（作业控制）和 CONFIG_ASH_ALIAS（别名支持）。我遇到过有人只开了 ash 的基本功能，结果脚本里用 jobs 命令直接报错，排查了半天才发现是配置没开全。
另外，关于 Shell 的大小：
| Shell 类型 | 典型大小（x86） | 功能完整性 | 推荐场景 |
|---|---|---|---|
| ash | ~80KB | 高 | 通用嵌入式系统 |
| hush | ~40KB | 中 | 极端资源受限 |
| msh | ~30KB | 低 | 不推荐 |
你看，ash 虽然比 hush 大了一倍，但换来的是完整的脚本兼容性。我个人觉得，这 40KB 的空间花得值。
文本处理工具：grep、sed、awk 的取舍
文本处理工具是嵌入式系统的瑞士军刀。但问题是，这三把刀都很重。
我来说说我的取舍策略：
- grep：必选。日志过滤、配置查找、进程状态检查，都离不开它。但注意，BusyBox 的 grep 默认不支持
-P（Perl正则）和-o（只输出匹配部分）。如果你需要这些功能，记得在配置里打开CONFIG_FEATURE_GREP_EGREP_ALIAS和CONFIG_FEATURE_GREP_CONTEXT。 - sed：看情况。如果你需要在启动脚本里做文本替换，比如修改配置文件中的 IP 地址，那 sed 是神器。但如果你只是偶尔用一次，完全可以用
awk或者 shell 的字符串替换替代。我做过一个项目，启动脚本里只有一处需要 sed，我直接用${var/old/new}搞定了，省掉了 sed 的 20KB 空间。 - awk：这个最纠结。awk 功能强大，但体积也大（约 60KB）。我的建议是：如果你的系统需要做复杂的文本解析，比如解析 /proc/meminfo、/proc/stat 等，那 awk 值得选。但如果只是简单的按列切割，用
cut或者 shell 的read就够了。
一个真实的案例：我之前做一个智能网关项目，需要在启动时解析 /proc/net/dev 获取网口流量。一开始我用了 awk，后来发现 awk 占的空间太大，就改用 cat /proc/net/dev | while read line; do ... done 配合 cut 和 tr 实现。虽然代码长了点，但省下了 60KB 空间。对于只有 2MB Flash 的设备来说，这很值得。
另外，还有一个容易被忽略的工具：vi。很多嵌入式工程师喜欢在设备上保留 vi，方便现场调试。但 vi 的体积很大（约 100KB）。我的建议是：开发阶段保留 vi，量产阶段去掉。量产后的设备，一般只需要通过 Web 或远程接口管理，很少需要直接编辑文件。
知识体系总览
下面这张图，是我总结的核心 Applets 选择逻辑。你可以把它当作一个决策参考：
总结一下
说白了，Applets 的选择就是一个权衡的过程。你要在功能完整性和资源占用之间找到平衡点。
我的建议是：
- 先全选，再逐步剔除。 开发阶段把所有可能用到的 Applets 都编译进去，然后通过实际运行，看看哪些是真正需要的。
- 用脚本替代大工具。 能用 shell 循环、字符串操作解决的问题，就别上 awk、sed。代码写起来麻烦点，但空间省下来了。
- 区分开发版和量产版。 开发版保留 vi、awk、find 等调试工具，量产版只保留最小集。
- 测试，测试，再测试。 去掉一个 Applets 之前，一定要跑一遍所有的启动脚本和应用逻辑。我曾经因为去掉了
tr，导致一个日志解析脚本崩溃，排查了整整两天。
嗯，关于核心 Applets 的选择策略，今天就聊到这里。记住：少即是多。在嵌入式世界里，每一字节都很珍贵。
一个小技巧：用 busybox --list-full 可以查看当前 BusyBox 支持的所有 Applets。然后对照你的需求清单，一个一个勾选。别偷懒，这个清单值得花时间做。
可可精品资料库