企业官网建设流程全解析

做嵌入式开发的人，手里大概率都有一台 x86 笔记本，却经常要跟 ARM64 打交道。以前交叉编译一个程序，编译完只能打包丢到 ARM 板子上跑，本地想验证一下，不是传文件就是连串口，来回折腾一次怎么也要几分钟。qemu-aarch64-static 就是用来打破这个循环的：它在用户态模拟 ARM64 指令，让 x86 机器能直接执行 aarch64 的 ELF 程序，不用起虚拟机，也不用接开发板。这篇文章我会从它为什么能跑、怎么配、怎么用、怎么调试，写到那些文档里不会写的坑，一次性讲清楚。整篇面向搞嵌入式、搭 CI、或者需要给 ARM64 交叉编译和测试的开发者，新手可以直接照着做，老手也可以拿后半部分的排查清单当参考。

1. qemu-aarch64-static 是什么，解决什么问题

1.1 用户态模拟与全系统模拟的本质区别

很多人第一次听说 qemu-aarch64-static，会把它和 qemu-system-aarch64 搞混。两者虽然都叫 QEMU，工作方式完全不同，适用场景也完全不同。

qemu-system-aarch64 是全系统模拟，相当于在软件里虚拟出一整台 ARM 机器：CPU、内存、中断控制器、串口、网卡、磁盘控制器都得模拟。它跑的是完整的 Linux 内核，guest 内核里头再跑应用。所以它能测内核模块、驱动、甚至裸机固件，但代价是慢，速度通常只有原生的十分之一甚至更低，而且需要准备磁盘镜像、内核镜像这些额外的东西，配置成本也不低。

qemu-aarch64-static 属于用户态模拟。它不模拟硬件，只模拟 ARM64 的 CPU 指令集和系统调用接口。host 上直接有一个现成的 Linux 内核，qemu 把 ARM64 程序的每条指令翻译成 x86 指令，再把程序发起的系统调用转成 host 内核能理解的调用，然后原样返回结果。应用层的行为几乎和真实 ARM 环境一致，速度通常能到原生的 20% 到 50%，对于跑测试、跑编译脚本、验证命令行工具来说完全够用。

要说清楚的一点是：用户态模拟解决的是“用户程序能不能跑”的问题，不是“内核能不能启动”的问题。凡是涉及内核模块、设备驱动、裸机代码的验证，还是得用全系统模拟或者真机。这个边界搞清楚了，后面遇到“为什么我的驱动模块跑不起来”之类的问题就不会自乱阵脚。

1.2 为什么嵌入式开发和 CI 场景里几乎绕不开它

先说交叉编译。我们在 x86 上通过 aarch64-linux-gnu-gcc 编译 ARM64 程序，编译器这边没问题，难的是验证。以前的做法是把产物同步到开发板，板上跑一遍，结果再传回来。没有网络的环境、没有板子的远程 CI、或者刚改了一行代码想快速回归，这个循环的成本会被放大到让人烦躁。

有了 qemu-aarch64-static，本机就能直接跑这些 ARM64 二进制。嵌入式开发里最常见的操作——跑单元测试、验证命令行参数、检查崩溃日志、跑一遍安装脚本，都可以在 x86 机器上完成。很多团队现在会先把交叉编译的产物在 qemu 里过一遍再发板子，等于用软件把大批低级错误提前过滤掉了，板子只用来做硬件相关的最后验证。

CI 场景更直接。如果流水线要在 x86 runner 上构建并验证 arm64 镜像，比如为 ARM 服务器或嵌入式设备制作系统镜像，没有 qemu-aarch64-static 就得专门准备 ARM 硬件，或者在云上排队等 arm64 机器。有了它，注册好 binfmt_misc，就可以在 x86 runner 里直接构建和运行 arm64 容器，整个流程对跑流水线的人来说几乎透明。后面第 4 章我会给出一个完整的 rootfs 制作案例，照做就能在本地跑出一套 arm64 环境。

2. 原理剖析：指令翻译、系统调用与 binfmt_misc 的配合

2.1 为什么这里强调 “static”

qemu-aarch64-static 的 “static” 指的是静态链接版本，不依赖宿主机的共享库。嵌入式场景里，大家几乎默认用 static 版本，原因有三个。

第一，静态链接意味着只有一个独立的二进制文件，可以把它拷贝到任何 Linux 环境的 rootfs 里直接使用，不用在目标环境安装一堆运行库。第二，做 chroot 或容器内模拟时，不会因为 host 和 guest 的 libc 不同而出现符号解析问题。第三，binfmt_misc 注册的解释器路径是绝对的，如果注册的是动态版本，解释器加载时还需要 host 上的动态链接器和库，环境一变就容易出幺蛾子，静态版本从根上把这些麻烦消掉了。

要留意的是，不同发行版的 qemu-user-static 包名可能略有不同，有的是 qemu-user-static，有的是 qemu-user-binfmt。安装完之后，确认一下 /usr/bin/qemu-aarch64-static 存在且是静态链接的，用 file 命令就能看出来。如果是 Script 或者动态链接的，就找找对应的 static 包。

2.2 TCG 二进制翻译的工作方式

QEMU 用户态模拟的指令翻译依赖 TCG（Tiny Code Generator）。流程可以简化成一句话：把一段 ARM64 机器码翻译成等价的 host 指令，然后执行。

微观机制大致是：QEMU 按基本块为单位读取 guest 指令，先翻译成一组中间表示 TCG IR，再把 TCG IR 优化并翻译成 x86 指令，放进 translation cache。下一次再执行到同一个代码块时，直接命中缓存，不用重新翻译。你可以把它理解成同声传译：不是逐字硬翻，而是听完整句话再转述，遇到经常重复的表达，第二次几乎不用思考就能直接说出来。循环体、热路径代码在 qemu 里跑着跑着会越来越快，原因就在这。

TCG 翻译本身有开销，所以计算密集型的程序在 qemu 下跑，性能损失会比直觉上更明显。指令多、基本块跳转频繁的代码，翻译和缓存命中率决定最终性能。如果是拿它交叉编译一个大型项目，在 qemu 里跑构建会比原生慢不少，但相比“把代码传到板子上再编译”的往返时间，仍然是可以接受的折中。我个人的经验是：小工具和测试代码用 qemu 跑很舒服，大型构建宁可走交叉编译后在 qemu 里做冒烟测试，也不要直接在模拟环境里全量编译。

2.3 系统调用翻译：让 “外语程序” 和 “本地内核” 对话

比指令翻译更关键的一层是 syscall 翻译。ARM64 程序里执行 svc 指令会进入系统调用，在用户态模拟下没有 guest 内核，这个陷入动作会被 qemu 截获。qemu 拿到系统调用号和参数后，按照 ARM64 ABI 解析参数，映射成 host 上对应的系统调用，再通过 host 内核完成实际工作，最后把返回值转换成 ARM64 程序期望的格式。

文件读写、网络 socket、多线程、内存映射这些常见操作，翻译层都能正常处理。所以你会发现，绝大多数用户态程序在 qemu-aarch64 下都能“直接跑起来”，几乎感觉不到中间隔着一层翻译。需要注意的是一些特殊的 ioctl、与硬件特性绑定的 syscall，翻译层可能不支持或者行为有差异。遇到这类问题，常规做法是调整代码把相关调用移出去，或者只在真机上做最终验证。

还有一点：用户态模拟下，进程看到的系统信息，比如 /proc/cpuinfo、/sys 里的设备信息，其实来自 host 内核，不是 ARM 机器的。如果程序里有读取 cpuinfo 判断架构、根据设备树节点做分支的逻辑，在 qemu 下拿到的是 x86 数据，这个差异会让程序行为跟真机不完全一样。能做的就是在代码里避免强依赖这些运行时探测，或者设置好环境变量、用 -cpu 参数尽量贴近目标硬件。

2.4 binfmt_misc：让内核认识 ARM64 程序

把 qemu-aarch64-static 和 binfmt_misc 配合起来，才是真正的“无缝体验”。Linux 内核的 binfmt_misc 模块允许为一种二进制格式注册一个解释器。当内核尝试 exec 一个文件时，会读取文件开头的 magic 字节和格式特征，如果匹配到注册规则，就把文件路径作为参数交给注册的解释器去执行。

ARM64 的 ELF 文件头部有一个固定的字段表示机器类型 EM_AARCH64。注册规则大致是：magic 匹配到这个特征，解释器填 /usr/bin/qemu-aarch64-static。这样一来，在 x86 主机上直接执行一个 ARM64 程序，内核发现它不像本地可执行文件，就自动调用 qemu-aarch64-static 来执行。用户看到的效果是：chmod +x app && ./app 就直接跑了，完全感觉不到中间的解释层。

在 systemd 系发行版中，安装 qemu-user-static 后通常会自动生成 /usr/lib/binfmt.d/qemu-aarch64.conf。容器环境里，安装包也会带上 qemu-binfmt-conf.sh 帮你注册规则。注册信息可以在 /proc/sys/fs/binfmt_misc/ 下面看到。如果注册失效，表现就是执行 ARM64 程序时直接报 “Exec format error”，这个后面第 5 章会重点展开。

3. 安装与配置：把 x86 变成能跑 ARM64 程序的机器

3.1 安装 qemu-user-static

安装本身不复杂，我按常见发行版的路数写一下。

Debian 系发行版用 apt 安装：

sudo apt update sudo apt install qemu-user-static

Arch 系可以用 pacman 安装，包名也是 qemu-user-static：

sudo pacman -S qemu-user-static

Red Hat 系发行版用 dnf：

sudo dnf install qemu-user-static

安装完之后，先确认一下工具到位了：

which qemu-aarch64-static file /usr/bin/qemu-aarch64-static

应该能看到它是一个静态链接的 ELF 可执行文件。同时检查一下 binfmt 注册情况：

ls /proc/sys/fs/binfmt_misc/

正常情况下能看到 qemu-aarch64 这样的条目。如果在容器里跑，宿主机的 binfmt 规则不一定能直接穿透到容器，要在容器里再注册一次，这个问题我们 3.2 节专门说。

3.2 注册 binfmt_misc 的常见方式

注册 binfmt_misc 本质上是往 /proc/sys/fs/binfmt_misc/register 写一段规则文本。写这段文本需要管理员权限，在容器里还需要 privileged 模式，否则没有权限操作 /proc/sys/fs/binfmt_misc/。

手动注册的方式是：

sudo sh -c 'echo ":qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-aarch64-static:F" > /proc/sys/fs/binfmt_misc/register'

这段 magic 匹配的是 64 位 ARM ELF 文件的头部特征，最后一个 F 表示开机自动加载。不过实际日常使用中，很少需要手敲这么长的规则，发行版安装包和容器镜像一般都会提前配好。

systemd 系发行版可以用：

sudo systemctl restart systemd-binfmt systemctl status systemd-binfmt

容器内则通常是在 docker run 的时候加上 --privileged，或者用 qemu-binfmt-conf.sh 脚本重新注册：

sudo qemu-binfmt-conf.sh --qemu-suffix-static --qemu-path /usr/bin

注意：在 WSL2 里，systemd-binfmt 有时候没有自动启用，需要手动确认 /proc/sys/fs/binfmt_misc/ 是否有内容。如果目录是空的，手动执行一次上面的 echo 注册命令就能解决问题。

3.3 三种运行 ARM64 程序的方式，按场景选

第一种：直接运行。注册好 binfmt_misc 后，普通用户在 shell 里执行 ./app，内核自动调用 qemu-aarch64-static。这是最舒服的方式，适合日常开发和测试。

第二种：手动指定解释器。在没注册 binfmt_misc 的环境里，可以显式执行：

qemu-aarch64-static ./app

这种方式不依赖内核的 binfmt 机制，临时验证很实用，尤其是在别人的机器上、不方便改系统配置的时候。

第三种：chroot 或容器环境。做法是把 qemu-aarch64-static 拷进目标 rootfs 的 /usr/bin/ 下，然后 chroot 进去，再在 rootfs 里直接执行 ARM64 程序。这种方式适合制作、调试完整的 ARM64 文件系统，比如你要为一个 ARM 设备定制一套系统目录结构，就可以用这个方式在 x86 上完成绝大部分软件安装和配置工作。

4. 实战演练：运行、编译、调试与构建完整 ARM64 环境

4.1 编译并运行第一个 ARM64 程序

先从一个最简单的程序开始。写一个 hello.c：

#include <stdio.h> int main(void) { printf("hello from aarch64\n"); return 0; }

在 x86 机器上安装交叉编译器：

sudo apt install gcc-aarch64-linux-gnu

静态编译：

aarch64-linux-gnu-gcc -static -o hello hello.c

然后直接运行：

./hello

如果 binfmt 配置正确，屏幕会输出 hello from aarch64。第一次跑这个程序的时候，可以明显感觉到启动比原生程序慢一点，因为 qemu 要先做指令翻译，之后热路径被缓存，后续执行会快很多。

这一步跑通，说明你的整条链路是通的：交叉编译器能产出 ARM64 ELF，binfmt 注册有效，qemu-aarch64-static 能在这个版本的内核上正常工作。如果这一步就卡住，问题多半在 binfmt 注册或者 qemu-user-static 没装好，先回到第 3 章排查。

提示：静态编译的 -static 参数在这里很关键。动态编译的程序需要一个 ARM64 的 libc 才能运行，光有交叉编译器还不够，还要指定 sysroot。静态编译可以绕过这一层，先验证模拟器本身没毛病，后面再上动态链接。

4.2 交叉编译动态链接程序：sysroot 与 -L 选项

日常开发的程序很少全静态编译，多半要动态链接 glibc，这时候就需要 sysroot。简单说，sysroot 是目标系统根文件系统的一个副本，里面装着 ARM64 版本的 libc、动态链接器和其他库。

Debian 系发行版可以用这个命令安装基础 sysroot：

sudo apt install libc6-arm64-cross

sysroot 默认路径通常是 /usr/aarch64-linux-gnu。交叉编译时用 --sysroot 指定：

aarch64-linux-gnu-gcc --sysroot=/usr/aarch64-linux-gnu -o hello hello.c

编译出来的程序是动态链接的，运行它的时候 qemu 需要知道去哪里找 ARM64 的动态链接器和共享库。qemu-aarch64-static 提供了 -L 参数：

qemu-aarch64-static -L /usr/aarch64-linux-gnu ./hello

如果已经用 binfmt 自动执行，没法手动加 -L，可以通过环境变量 QEMU_LD_PREFIX 指过去：

export QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ./hello

这个技巧几乎每天都会用到。很多刚接触 qemu-aarch64-static 的人，静态编译跑得好好的，换成动态链接就报 “error while loading shared libraries”，其实就是没告诉 qemu 去哪里找 ARM64 版本的库。

4.3 用 qemu-aarch64-static 构建并运行 ARM64 容器镜像

现在到了最有意思的部分：在 x86 机器上构建一个完整的 ARM64 rootfs，然后用 qemu-aarch64-static 把它跑起来。这一步是 CI 制作 arm64 镜像最常用的手段。

先用 debootstrap 拉一套 ARM64 的最小文件系统：

sudo debootstrap --arch=arm64 --foreign bookworm /tmp/arm64-rootfs

首次 debootstrap 会在目标目录里准备一个最小的系统，但里面还不能直接 chroot 执行 ARM64 的二进制，因为此时没有 qemu 解释。把 qemu-aarch64-static 拷进去：

sudo cp /usr/bin/qemu-aarch64-static /tmp/arm64-rootfs/usr/bin/

接着 chroot 进去执行第二阶段的配置：

sudo chroot /tmp/arm64-rootfs /debootstrap/debootstrap --second-stage

这一步会利用 qemu-aarch64-static 模拟 ARM64 环境，把 debootstrap 的后续安装全部跑完。跑完之后，这个目录就是一个能用的 ARM64 环境，可以 chroot 进去干活了：

sudo chroot /tmp/arm64-rootfs /bin/bash

进去之后可以正常使用 apt 安装软件包，安装的软件都是 ARM64 版本。这个 rootfs 可以直接打包成镜像，也可以用来验证安装脚本在 ARM64 上的行为。

这个过程常见的问题有两个：一是 chroot 进去之后 apt 拉不到源，多半是 DNS 解析问题，需要把宿主机的 /etc/resolv.conf 拷进 rootfs；二是挂载点不全，需要手动挂载 /proc 和 /sys：

sudo mount -t proc /proc /tmp/arm64-rootfs/proc sudo mount -t sysfs /sys /tmp/arm64-rootfs/sys

搞完记得卸载，避免后台进程还占着文件系统。

4.4 远程调试 ARM64 程序：qemu 当 gdbserver 用

开发板上没有调试器，或者串口调试太费劲的时候，可以让 qemu-aarch64-static 充当 gdbserver，在 x86 本地用 gdb 远程调试 ARM64 程序。

先用 -g 参数启动程序，监听 1234 端口：

qemu-aarch64-static -g 1234 ./hello

程序会停在运行之前，等待调试器连接。在自己本机（x86 机器）上运行支持多架构的 gdb：

gdb-multiarch ./hello

在 gdb 里设置目标架构并连接：

set architecture aarch64 target remote :1234

然后就能像平常一样打断点、看寄存器、单步执行：

break main continue info registers

这种方式在排查崩溃、分析汇编层行为时非常方便。我试过用它调试过一段涉及浮点运算的崩溃问题，在 gdb 里能看到 ARM64 的向量寄存器状态，几下就定位到了问题，比自己拿开发板加打印日志快得多。

需要注意的一点是：qemu 模拟出来的执行环境不是完全一致的硬件环境，某些涉及内存布局、cache 行为、外设映射的问题，在 qemu 里复现不出来。这种调试适合逻辑层面的排查，遇到硬件相关的问题还是得回到真机。

4.5 接入 CI 流水线做跨架构回归

把 qemu-aarch64-static 整合进 CI，价值最大的场景是：让 x86 的 runner 能构建、测试 arm64 的程序或镜像。

在流水线里，通常会先把 binfmt 注册好，然后让容器引擎直接运行 arm64 的镜像。做法是：

docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

这一步会往宿主机注册全局的 binfmt 规则，之后容器引擎就能直接跨架构拉取并运行 arm64 镜像。

之后再跑：

docker build --platform linux/arm64 -t my-app:arm64 .

就能在 x86 上构建 arm64 镜像。运行测试时也一样，直接用 --platform linux/arm64 拉取并执行容器，容器内部需要安装的程序都是 ARM64 版本，测试的结果也是 ARM64 环境下的结果。

CI 里容易踩的坑是 runner 本身的安全策略。有些 runner 不允许特权容器，或者 seccomp 策略限制了 binfmt_misc 的注册，表现就是镜像拉下来了，但容器一启动就报 exec format error。这种情况下，要么给 runner 开特权，要么换用支持 binfmt_misc 的 runner 环境，没有太多绕过空间。

4.6 性能观察与简单调优

用 qemu-aarch64-static 跑程序，性能到底怎么样，这是很多人关心的问题。我的经验是：纯整数计算程序大约能跑到原生 30% 左右；浮点密集的程序会低一些，大概 20%；IO 密集、网络密集的程序因为大部分时间在内核态，模拟损失相对小，差异不太明显。

如果觉得性能偏低，可以考虑几个方向。

第一个是 CPU 模型。qemu 默认的 CPU 模型比较保守，可以指定更贴近目标硬件的模型：

qemu-aarch64-static -cpu max ./app

第二个是 QEMU_CPU 环境变量。在 binfmt 自动执行的环境里，无法手动加 -cpu 参数，就用环境变量：

export QEMU_CPU=max

第三个是避开太老的 qemu 版本。老版本对新的 ARM64 指令支持不全，遇到不认识的指令会走慢速路径，甚至直接报错。升级 qemu-user-static 到新版本经常能带来实打实的性能改善。

我实际用的策略是：日常测试和单测用默认配置，遇到跑批量的构建任务或者压力测试，就用 -cpu max 提一下性能。跑大型构建还是尽量交叉编译，不要在 qemu 里做全量编译，时间和资源上不划算。

5. 常见踩坑与排查清单

5.1 binfmt 注册失效，执行报 Exec format error

这是最经典的问题。明明 qemu-aarch64-static 安装好了，执行 ARM64 程序却报 “Exec format error”。

原因通常是 binfmt_misc 的注册条目丢了。容器重建、systemd-binfmt 没启动、宿主机重启之后没重新注册，都会导致这个问题。

排查步骤很简单：

ls /proc/sys/fs/binfmt_misc/

如果看到 qemu-aarch64 条目，注册是在的；如果没有，重新执行第 3 章的注册命令。如果条目在但还是报错，看看注册信息里的解释器路径是不是 /usr/bin/qemu-aarch64-static，以及这个路径是否真实存在。

5.2 动态链接程序报 “error while loading shared libraries”

交叉编译出来的动态链接程序，在 qemu 下跑时报找不到共享库。这个问题的本质是 qemu 不知道去哪里找 ARM64 版本的库。

解决方式有两个，前面 4.2 也提过：手动运行加 -L 参数，或者设置 QEMU_LD_PREFIX 环境变量。如果是 chroot 环境，还要确认 rootfs 里有对应版本的 libc，而且路径和程序的 ELF interpreter 期望一致。

用 readelf 看程序期望的动态链接器路径：

readelf -l app | grep interpreter

如果程序期望的是 /lib/ld-linux-aarch64.so.1，而 rootfs 里这个文件不存在，那就得检查 sysroot 是否完整。

5.3 32 位 ARM 程序跑不起来

另一个容易忽视的点：aarch64 是 64 位 ARM，但还有很多程序是 32 位 ARM（armv7、armhf）。qemu-aarch64-static 只能解释 64 位 ARM 指令，32 位的 ARM 程序需要 qemu-arm-static。

检查一个 ELF 是 32 位还是 64 位：

file app

如果是 “ELF 32-bit LSB executable, ARM”，那就要确认 /usr/bin/qemu-arm-static 是否安装，以及 binfmt 里有没有对应的注册条目。很多人第一次做嵌入式交叉编译，传了个 armhf 程序到 aarch64 的 qemu 环境里去跑，调用链断在这一步还不自知。

5.4 运行时报 syscall 不支持或功能异常

有些程序在 qemu-aarch64-static 下运行时报 “Fatal: syscall not implemented” 或者直接崩溃。这通常是因为 qemu 版本太老，guest 程序用了一些新内核才加入的 syscall，或者是一些 qemu 长期没有实现的特殊调用。

遇到这个问题，第一步是升级 qemu-user-static 到最新版本，能解决大部分因为 syscall 缺失导致的问题。如果升级之后还报，可以查一下 qemu 的 changelog 或者 issue 列表，看看是否已知问题，有没有 workaround。大多数情况下，改代码绕开这个 syscall 比等 qemu 支持更快。

5.5 容器内权限和安全策略导致失败

在容器场景下，常见的使用链是：容器内安装 qemu-user-static，注册 binfmt，然后构建 arm64 镜像。如果容器没有特权模式，注册 binfmt 会失败，表现为操作 /proc/sys/fs/binfmt_misc/register 时报权限不足。

解决方式是在启动容器时加 --privileged，或者按 4.5 的方式先由宿主机注册好 binfmt，再让容器只用解释器，不重新注册。如果宿主机的安全策略比较严格，AppArmor 或 seccomp 可能会拦截 qemu 的某些 syscall，这种情况在日志里能看到 seccomp 相关的报错，需要调整对应的安全配置。

5.6 性能异常慢或卡死

如果出现极端慢的情况，先确认是不是所有程序都慢，还是单个程序慢。所有程序都慢，要看 qemu 版本、CPU 模型是否合理；单个程序慢，要看程序本身是否有密集的浮点运算、原子操作或者频繁的 syscall。

还有一种情况是程序在 qemu 下“卡死”，看起来没有响应，实际上可能是在等待某个 ioctl 返回，或者陷入了一个翻译层不支持的死循环。用 gdb 连接上去看看当前执行位置，基本就能分辨是死锁还是单纯的慢。

最后放一个速查表，遇到问题先对着看：

我在实际用 qemu-aarch64-static 的过程中，最深的体会是：它不是一个“替代真机”的方案，而是一个“提前验证”的方案。能在 x86 上把大量低级问题、动态库问题、ABI 问题先暴露出来，省下来的板子测试时间非常可观。但它终究是翻译执行，遇到硬件相关、内核相关的行为差异时，不要怀疑是模拟器 bug，先想想是不是环境差异导致的。把这条边界想清楚，qemu-aarch64-static 在嵌入式开发里的价值就能发挥到最大。最后再分享一个小技巧：在做完 rootfs 制作之后，记得把拷进去的 qemu-aarch64-static 删掉，否则打包出来的镜像会包含 x86 痕迹，在真机 ARM 环境里反而会造成干扰。这个细节，打包镜像的人多半都会踩一次。