一句话结论：嵌入式 Linux 的用户态系统层，真正决定产品体验的不是内核版本，而是启动链的每一段是否都被测量与控制过。工具链不一致会让同一份代码在不同机器上行为不同；根文件系统多塞一个库会让镜像胖30% 并且启动慢两秒；init 顺序错会让服务在依赖未就绪时反复重启；日志刷在错误的位置会让现场问题无法复现。本文把这些点逐条变成可测量、可判据化的工程项——启动多少秒、镜像多少兆、峰值多少内存、断电后能否恢复，每一项都有量化判据。

这份文档解决什么

本文是用户态系统层的专项指南：讲清嵌入式 Linux 从上电到应用运行之间的全部用户态环节——工具链与构建体系、Bootloader 交接、根文件系统怎么搭、init 用什么、服务怎么编排、进程与线程怎么组织、异步 IO 怎么写、网络怎么接、崩溃怎么抓、性能怎么测、安全怎么加固、电源怎么管、OTA 怎么做、容器能不能用。内核侧（内核配置、设备树、内核态驱动、内核调试）由《Linux 内核开发指南（BSP Kernel）》承接；存储软件栈（FTL、文件系统、掉电一致性）由《嵌入式文件系统开发指南》承接；具体 Flash 器件驱动由《SPI NOR / SPI NAND / PPI NAND / eMMC 驱动开发指南》系列承接。本文站在它们之上，只讲用户态。

读者路径

版本基线与引用约定

• 内核以 Linux 6.1 / 5.15 LTS 为基线，PREEMPT_RT特性以 6.1-rt 为参照；
• 用户态以 glibc 2.36 / musl 1.2、systemd 252、BusyBox 1.36、Buildroot 2024.02、Yocto 4.0 为基线；
• 命令示例在 MPU 平台可直接使用；MCU 平台若跑 uClinux / NuttX，本文概念仍适用，具体命令以该系统文档为准；
• 内核态内容见《Linux 内核开发指南（BSP Kernel）》，存储栈见《嵌入式文件系统开发指南》，本文不重复。

1 · 用户态系统层全景

内核能跑起来只是起点。真正决定产品表现的是内核之下、内核之上的那一层：工具链怎么搭、Bootloader 交什么给内核、根文件系统里放了什么、服务按什么顺序起。这一章先把这条链路的全景摊开。

1.1 与内核篇的分工边界

两个文档的边界很清晰：内核篇讲内核返回用户态之前的事，本篇讲之后的事。但工程上出问题的地方，往往就在这条接缝上——设备树被应用层覆盖、挂载点不存在导致服务反复重启、内核已经 probe 成功但用户态找不到 /dev 节点。

1.2 从上电到第一个应用的九个阶段

图 2 下半部分的「责任方」列是本章最有价值的部分：每一段耗时归属于不同的团队与不同的工具。启动优化之所以难，往往不是因为某段特别慢，而是因为没人知道自己负责的那段占了多少。

1.3 用户态系统层的六个子系统

1.4 本文覆盖范围与前置约定

2 · 交叉工具链与构建体系

工具链是所有后续工作的地基。它出问题时症状往往很奇怪（链接过但运行崩、同一份代码在不同机器上行为不同），所以必须在项目一开始就固定下来。

2.1 工具链的四段构成

2.2 sysroot 与动态链接

# 一份可直接抄的交叉编译变量定义
TOOLCHAIN_PREFIX = /opt/toolchain/arm-linux-gnueabihf-
SYSROOT         = $(TOOLCHAIN_PREFIX)/sysroot

export CROSS_COMPILE = $(TOOLCHAIN_PREFIX)
export CC       = $(CROSS_COMPILE)gcc
export CXX      = $(CROSS_COMPILE)g++
export STRIP    = $(CROSS_COMPILE)strip
export OBJCOPY  = $(CROSS_COMPILE)objcopy
export LD       = $(CROSS_COMPILE)ld

# 关键：所有头文件与库都限定在 sysroot 内
export CFLAGS = --sysroot=$(SYSROOT) -march=armv7-a -mfpu=neon \
                -mfloat-abi=hard -O2 -g -Wall -Wextra
export LDFLAGS = --sysroot=$(SYSROOT) -Wl,-rpath-link=$(SYSROOT)/lib

# 静态构建（每个程序独立、无运行时依赖）
STATIC_FLAGS = -static

# 混合构建（共享 libc）
SHARED_FLAGS = -Wl,-rpath=/usr/lib

# 自检：构建第一步就打印 sysroot 与 libc 架构
build-check:
	@echo "SYSROOT = $(SYSROOT)"
	@$(CC) -print-sysroot
	@$(CC) -dumpmachine
	@echo 'int main(void){return 0;}' | $(CC) -x c - -o /tmp/t.bin \
	    && file /tmp/t.bin

2.3 Buildroot 与 Yocto 的对比

2.4 手工构建根文件系统的步骤

这八步存在的意义不是「替代 Buildroot」，而是让你在 Buildroot 出问题时知道它到底做了什么。很多现场问题（镜像里少了某个 so、服务启动了但依赖库没进去）只有手工打过一遍的人才能快速定位。

2.5 构建可复现性的工程要求

3 · Bootloader 与启动流程

Bootloader 是嵌入式系统里最容易被低估的一段代码。它只在上电后运行几百毫秒，却决定了后面所有环节的起点：内存对不对、设备树对不对、启动参数对不对、内核从哪来。这三个「对不对」任何一处出错，表现出来的都是「系统起不来」，而排查线索往往已经随串口日志一起消失了。

3.1 从上电到内核接管：五级引导链

五级不是必须的，但对绝大多数带 DDR 的 SoC 来说，BootROM 与 U-Boot 之间必须有 SPL，原因是 BootROM 体积被限制在几十 KB，它做不了「初始化复杂 DDR 控制器」这种需要几百行寄存器配置的事。

3.2 环境变量与 bootargs：同一件事的两面

环境变量与 bootargs 最大的工程陷阱是它们的持久化方式。环境变量存在存储分区里，带着两段 CRC；bootargs 通常直接写在 U-Boot 源码的默认配置或 defconfig 里。前者可能被意外覆盖，后者不会——两者的行为差异决定了备份策略。

# U-Boot 中查看与修改环境变量
printenv                # 打印全部
printenv bootargs       # 只看一条
setenv bootargs 'console=ttyS0,115200 root=PARTUUID=1234-5678 rootfstype=ext4 rw'
saveenv                 # 写入存储（需要先 protect off 某些平台）
saveenv -f               # 强制保存，跳过 CRC 检查

3.3 设备树在引导阶段的处理

3.4 A/B 分区与自动回滚

但它也有明确的失效边界，必须在设计阶段就想清楚：

4 · 根文件系统构建

根文件系统是内核之外的一切。它不参与内核启动，但决定了「内核起来之后这个设备到底能做什么」。这一章回答三个问题：里面该放什么、怎么组合、怎么把体积压到目标以内。

4.1 根文件系统的内容清单

4.2 只读根与可写层的四种组合

四种方案没有优劣之分，只有适配与不适配。真正需要判断的是两个问题：这个设备的数据要活多久，以及出问题后现场的人能不能重新刷机。第一个问题决定选方案二还是三，第二个问题决定选方案二还是四。

# 方案二/三 的 overlay 挂载示例（写入 fstab 或 systemd unit）
# lower 为只读镜像，upper 为可写层，work 与 lower/upper 必须同格式
/       /rootfs   squashfs  loop,ro,defaults        0 0
/dev/mmcblk0p2  /       ext4    defaults,noatime    0 1
# 结果：/ 看到的是 lower 叠加 upper 的视图

4.3 镜像格式选型

4.4 镜像瘦身：体积去了哪里

# 查清镜像里到底什么最占地方（比 du 更快，能看到未压缩真实占用）
du -x -h --max-depth=1 /target/rootfs | sort -h
find /target/rootfs -type f -size +1M -exec ls -lh {} \; | sort -k5 -h

# 构建后必查的三类冗余
find /target/rootfs -name '*.a' -o -name '*.la' -o -name '*.pyc'   # 编译中间产物
find /target/rootfs -name '*.h' -o -name '*.hpp' -o -name '*.so.debug'  # 开发期文件
ldd /target/rootfs/usr/bin/app   # 确认没有多余的库依赖