手上有台 ARM64 机器，想跑一个只有 x86-64 版本的命令行工具，或者想试试某个只发了 Windows 版的软件，第一反应往往是“开个虚拟机”或者“找台 x86 机器远程连过去”。这条路能走通，但代价是维护一整套虚拟机镜像、网络映射、文件共享，开机还得等。FEX-Emu是另一条路：一个面向 AArch64 宿主深度优化的用户态 x86/x86_64 指令翻译层，装好之后在Debian/Ubuntu的终端里敲一条命令就能把 x86 程序拉起来，不需要虚拟化、不需要改内核、不需要重启。这篇就把我在 Debian 12 和 Ubuntu 22.04/24.04 上把 FEX-Emu 从零跑通的全过程摊开讲：它和 QEMU、Box64 到底差在哪，RootFS 为什么绕不过去，Config.json 里哪几个字段真正影响体验，TSO 和 SMC 这两个开关怎么取舍，以及那些“程序能启动但一交互就崩”的坑都是怎么来的。适合已经能在 ARM 上正常用 Linux、想进一步扩大软件可用范围的人，也适合只想搞清楚“这玩意到底能不能替代虚拟机”的读者。
1. 先搞清楚 FEX-Emu 是什么，再决定要不要用它
1.1 它解决的其实是二进制不兼容，不是算力不够
很多人第一次听说指令翻译层，会下意识觉得这是“性能妥协方案”，好像 ARM 跑不动才需要翻译。真实情况是反过来的：ARM64 上的多数日常任务并不缺算力，缺的是二进制格式对不上。内核的execve只认本机 ABI 的 ELF，你把一个 x86-64 的可执行文件拷到 ARM 机器上，chmod +x之后执行，内核直接回Exec format error。就算内核愿意加载，文件里写的解释器路径/lib64/ld-linux-x86-64.so.2在 ARM 系统上根本不存在，动态链接阶段就会断掉。
FEX-Emu 干的是在用户态把这条链接起来：接管 x86 ELF 的加载，把 x86 指令逐块翻译成 AArch64 指令，把系统调用改写成宿主能懂的调用，把图形、音频这类库调用“转发”给宿主的原生库。整个过程不涉及内核模块，不涉及虚拟化扩展，跑起来就是一个普通的用户进程，ps里能看到它，kill掉它就干净了。这一点对日常使用很关键——出问题的时候你面对的不是一台“坏掉的虚拟机”，而是一个普通的进程，排查手段完全不一样。
1.2 和 QEMU-user、Box64 的定位差异
这三个名字经常被混着提，但它们的设计目标差得挺远。我把实际用下来的感受整理成一张表，选型的时候对着看就行。
| 维度 | QEMU-user | Box64 | FEX-Emu |
|---|---|---|---|
| 翻译粒度 | 基本块翻译 + 代码缓存 | 动态重编译，块级 | 前端解码成 IR，后端生成 AArch64 |
| 支持的客户架构 | 非常多（x86、ARM、MIPS、RISC-V 等） | 主要 x86_64 | x86 与 x86_64 |
| RootFS 要求 | 通常需要-L指定 sysroot | 直接借用宿主库，依赖少 | 强依赖独立的 x86 RootFS |
| 图形栈处理 | 走客户机库，软件渲染居多 | 部分转发到宿主 | thunk 转发到宿主原生 GL/Vulkan |
| 上手难度 | 中，参数多 | 低，解压即用 | 中偏高，配置项多 |
| 典型场景 | 通用跨架构跑程序、调试 | ARM 板子上跑轻量 x86 工具 | 大型桌面程序、游戏类负载 |
简单总结：QEMU-user 是“什么都能跑但都跑不快”的万能钥匙；Box64 是“轻量、依赖少、板子友好”的务实派；FEX-Emu 是“冲着复杂负载去的”，它花了很大力气做多线程内存序模拟和图形栈转发，代价是配置复杂度和对宿主环境的挑剔程度都上去了。如果你只是想在一台小主机上跑个 x86 的编译脚本，Box64 完全够用而且更省心；如果你想跑的东西开了几十个线程、还要调 OpenGL，FEX 的优势才体现出来。
1.3 技术骨架：前端、IR、后端、Thunk、RootFS 五件套
理解这五个部件，后面所有的配置项就都能对上号了。
前端负责解码 x86/x86_64 指令。这块不是简单的一对一映射，x86 指令长度可变、前缀多、寻址模式复杂，前端要先把指令拆成结构化信息。
IR（中间表示）是 FEX 的核心设计。解码后的指令不会直接生成 AArch64 机器码，而是先落到一层与架构无关的中间表示上。这么做的好处是优化可以集中在 IR 层做，寄存器分配、常量折叠、死代码消除这些不用重复写两遍，后端换架构也不用动前端。
后端把 IR 编译成 AArch64 指令，结果扔进代码缓存。同一段代码第二次执行直接命中缓存，不用重新翻译——这就是为什么很多程序“第一次启动慢，后面就快了”。
Thunk是把客户机的库调用转发到宿主原生库的机制。比如 x86 程序调glXCreateContext，FEX 不会去模拟一整套 Mesa，而是通过 thunk 跳到宿主 ARM64 的 libGL 上。这是 FEX 能跑图形程序的关键，也是依赖宿主库版本最容易出问题的地方。
RootFS提供 x86 侧的基础运行库。这点下一节专门讲，因为它是新手装完之后第一个卡住的地方。
提示：这五个部件里，只有 Thunk 和 RootFS 是你能通过配置直接影响的，前端和后端属于代码里写死的东西。调优的精力应该全放在后面两个上。
2. 安装前的环境盘点与方案选型
2.1 硬件与内核侧的前置条件
动手之前先把几件事确认掉，能省掉后面一半的排查时间。
第一，确认宿主架构。uname -m输出必须是aarch64。有些发行版在 32 位 ARM 用户空间下跑 64 位内核，uname -m会显示armv7l，这种环境 FEX 装不上。
第二，看内核页大小。getconf PAGESIZE输出 4096 是最省心的。输出 16384 的话要留意——FEX 的代码缓存和内存映射对 16K 页的支持一直是个薄弱环节，某些发行版的 ARM 移植版默认用 16K 页，跑起来可能出现莫名其妙的段错误。遇到这种情况，我的建议是换一个 4K 页内核的发行版镜像，别在这上面耗。
第三，看 CPU 特性。lscpu里关注lse这一项，也就是 ARMv8.1 的原子指令扩展。有lse的机器，FEX 模拟 x86 强内存序时可以用硬件原子指令顶上，性能差距是数量级的；没有lse只能走 LL/SC 循环，多线程程序会慢到怀疑人生。ARMv8.0 的老板子不是不能跑，但要提前有心理准备。
第四，确认宿主库齐全。apt list --installed | grep -E 'libgl1|libvulkan1|libasound2'之类的命令扫一遍，thunk 转发依赖这些 ARM64 版本的库存在。宿主没有 libGL，客户机程序再完整也画不出东西来。
uname -m getconf PAGESIZE lscpu | grep -E 'Model name|Flags|CPU\(s\)' | head -5 ldconfig -p | grep -E 'libGL\.so|libvulkan\.so' | head第四步的输出为空不是致命问题，命令行程序不需要图形库，但如果你打算跑带界面的东西，这几个库必须补上。
2.2 三条安装路径，按你的耐心选
路径一：官方维护的 Ubuntu PPA。最省事，add-apt-repository加源、apt install，升级跟着系统走。适合 Ubuntu 用户，尤其是 22.04 和 24.04。缺点是源更新有滞后，想要最新特性得等。
路径二：官方 Release 页的 deb 包。版本最新，dpkg -i装完就能用，apt会帮你补齐依赖（缺依赖时先apt install -f）。适合 Debian 用户，或者想固定某个版本的场景。缺点是每次升级要手动下载，而且不同版本之间配置格式可能变。
路径三：源码编译。只有前两条走不通、或者你要改代码、要开调试符号的时候才考虑。依赖 clang 和 ninja，首次编译在八核 ARM 机器上大概十几到二十分钟，取决于你机器性能。
# 路径一：Ubuntu PPA（源地址以官方文档为准，这里只演示流程） sudo add-apt-repository ppa:fex-emu/fex sudo apt update sudo apt install fex-emu # 路径二：deb 包 wget <官方发布页给出的 arm64 deb 地址> sudo apt install ./fex-emu_*_arm64.deb # 路径三：源码编译骨架 sudo apt build-dep fex-emu 2>/dev/null || \ sudo apt install -y cmake ninja-build clang lld git python3 \ libsdl2-dev libepoxy-dev libdrm-dev libssl-dev libgtest-dev git clone --recursive https://<源码地址>/FEX.git cd FEX && mkdir build && cd build cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ .. ninja sudo ninja install我个人的选择是：主力机用 deb 包固定版本，测试机用源码编译跟着主线走。两种环境分开，出问题好对照。
注意：源码编译一定要带
--recursive。FEX 有若干子模块，漏了会在链接阶段报一堆找不到符号的错误，而且报错信息完全看不出是子模块没拉全。
2.3 RootFS：为什么这一步省不掉
这是新手最容易误解的地方。很多人以为 FEX 装完就完事了，结果一跑程序就报找不到/lib64/ld-linux-x86-64.so.2。
原因很简单：x86 程序绝大多数是动态链接的，运行时需要 x86 版本的动态链接器、libc、libstdc++、libgcc 等等。FEX 不去模拟这些库——模拟 libc 是个无底洞，工作量巨大而且永远追不上上游——它的做法是让你提供一个完整的 x86 根文件系统，程序在里面按正常路径找库，FEX 只负责翻译指令。这个根文件系统就是 RootFS。
用完整 RootFS 而不是零散装几个 .so，好处有三个：一是版本一致性有保证，libc 和 libstdc++ 的版本匹配问题不会出现；二是程序的依赖链条完整，不用一个个试缺哪个库；三是可以同时准备多套 RootFS，不同程序用不同发行版的基础环境，互不干扰。
代价是占空间，一套精简的 Ubuntu base rootfs 解压后三四百兆，完整桌面环境能到两三个 G。对现在的存储来说不算事，但 SD 卡用户要有数。
RootFS 有三种获取方式：用官方提供的取回工具交互式下载、手动下载发行版的 base tarball 解压、或者从一台 x86 机器上debootstrap出来再打包拷过来。第一种最省事，第二种最可控，第三种适合需要定制环境的场景。
3. 实操：在 Debian/Ubuntu 上把 FEX-Emu 跑起来
3.1 安装后的第一轮验证
装完之后别急着跑程序，先把工具箱里有什么搞清楚。FEX 装好通常会带几个可执行文件：主加载器（负责直接跑一个 x86 程序）、FEXBash（给你一个 x86 环境的 shell）、RootFS 取回工具、配置编辑器。
ls /usr/bin | grep -i fex # 典型输出（具体名字随版本略有差异）： # FEXLoader # FEXBash # FEXRootFSFetcher # FEXConfig # FEXServer /usr/bin/FEXLoader --help 2>&1 | head -20FEXBash这个工具值得单独说。它做的不是“开个 shell”，而是进入 RootFS 之后启动一个 x86 的 bash 进程。也就是说，你在里面敲的ls、cat、gcc都是 x86 版本，由 FEX 翻译执行。验证安装成没成，最快的办法就是进 FEXBash 敲uname -m——正常应该看到 x86_64，说明 FEX 已经接管了。
FEXBash # 进入后： uname -m # 期望输出：x86_64 cat /etc/os-release | head -3 exit如果uname -m还是 aarch64，说明你敲的还是宿主的 shell，RootFS 没挂上，回去检查配置。
3.2 生成并校验 RootFS
用官方取回工具是最稳的路子，它会下载、校验、解压、写配置一条龙。
FEXRootFSFetcher这个工具是交互式的，会列出发行版和版本让你选。默认给的是 Ubuntu 的 LTS 版本，对大多数程序够用。选完之后它会把东西放到~/.fex-emu/RootFS/下面，同时在~/.fex-emu/Config.json里写好路径。
手动方式适合需要精确控制的情况：
mkdir -p ~/.fex-emu/RootFS/MyRootFS cd ~/.fex-emu/RootFS/MyRootFS # 下载对应发行版的 x86_64 base rootfs tarball 后 sudo tar -xpf rootfs.tar.gz解压要用-p保留权限位，否则/usr/bin/sudo这类带 setuid 的文件权限不对，进去之后会各种奇怪报错。还有一个坑：有些 tarball 里带设备节点，普通用户解压会报错，用sudo或者加--exclude=dev/*跳过。
校验 RootFS 是否完整，最直接的办法是看关键文件在不在：
ls -l ~/.fex-emu/RootFS/MyRootFS/lib64/ld-linux-x86-64.so.2 ls -l ~/.fex-emu/RootFS/MyRootFS/lib/x86_64-linux-gnu/libc.so.6这两个文件缺失或者指向了错误的路径，后面的一切都跑不起来。另外注意从别的机器拷 RootFS 的时候，软链接容易断，用tar打包而不是cp -r，能保住链接关系。
3.3 Config.json 里真正影响体验的几个字段
配置文件在~/.fex-emu/Config.json，本质是个 JSON。字段名会随版本变化，所以我的建议是：先让工具生成一份默认的，然后只改你需要改的那几项，别整份手写。
结构大致长这样（不同版本字段可能有增减）：
{ "Config": { "RootFS": "Ubuntu_22_04", "RootFSPath": "/home/user/.fex-emu/RootFS/Ubuntu_22_04", "Emulator": { "TSOEnabled": true, "VectorTSOEnabled": true, "HalfBarrierTSOEnabled": true, "SMCChecks": "mtrack", "Multiblock": true, "X87ReducedPrecision": false, "MemcpySettings": "default" }, "ThunksDB": { "GL": true, "Vulkan": true, "ALSA": true } } }逐个说清楚哪几个值得动：
RootFSPath是唯一必须正确的字段。写错了所有程序都起不来，报错信息五花八门，但根子都在这。
TSOEnabled决定要不要模拟 x86 的强内存序。这个开关的影响最大，后面单独一节讲。
SMCChecks控制自修改代码检测的强度。mtrack是基于页表写保护的方案，精度高但会频繁触发信号；也可以选更轻的方案（有的版本用full/none），精度低但开销小。这个没有普适最优，得看你的程序行为。
Multiblock开启后，翻译器会把跨越跳转的连续基本块合并成一个更大的编译单元，减少跳转时的缓存查找开销。默认开，极少数程序开了反而慢，因为代码热区分散。
X87ReducedPrecision关系到老的浮点代码。x86 的 x87 单元是 80 位扩展精度，ARM 上只有 64 位 double，精确模拟需要软件实现，很慢。开了这个开关就用快速的近似实现，代价是极端情况下数值结果和真机不一致。
ThunksDB里的几项控制库转发的开关。图形和音频都关掉的话，程序只能跑纯命令行，但稳定性会好一些，因为不用跟宿主库版本较劲。
注意：改完 Config.json 之后，如果同时设了环境变量，环境变量的优先级更高。排查“为什么改了配置没生效”的时候，先
env | grep FEX_看一眼。
3.4 跑通第一个程序，用最简单的东西打底
别一上来就扔个复杂软件进去，先跑个纯命令行的、不带图形依赖的、单线程的东西，确认整条链路通。
# 方式一：通过 FEXBash 进去执行 FEXBash -c "cat /proc/cpuinfo | grep -m1 model" # 方式二：直接让加载器跑一个 x86 ELF FEXLoader /path/to/x86_binary --version程序能正常输出，说明加载、翻译、系统调用这几层都通了。这时候可以试试稍微复杂一点的：进 FEXBash 之后用包管理器装个工具。
FEXBash apt update # RootFS 里应该有对应的源配置 apt install -y bc file file /bin/ls exitfile会告诉你二进制是 x86-64 的，这本身也是一种验证——你在 ARM 机器上，装的是 x86 的包，跑起来了，这条链路就是完整的。
如果这一步就挂了，八成是 RootFS 里的 apt 源没配好，或者 DNS 不通。RootFS 是个独立环境，宿主配了代理不代表里面能通。在 FEXBash 里cat /etc/resolv.conf看一眼，DNS 配置对不上就手动写一个。
4. 关键参数调优：把“能跑”拉到“能用”
4.1 TSO：最值得花时间理解的一个开关
x86 的内存模型是强序的（TSO，Total Store Order），ARM 是弱序的。这个差异在单线程程序里看不出来，多线程一上来就是灾难：x86 上写好的无锁队列、自旋锁、双检锁，在 ARM 上直接重排，轻则数据错乱，重则卡死。
FEX 的应对是模拟 TSO——把客户机的每次原子操作和内存屏障都翻译成 ARM 上等效的、带屏障的序列。正确性有了，性能没了。这就是为什么很多人第一次跑 FEX 会感觉“怎么这么慢”，尤其是多线程程序。
三个相关开关要分清：
| 开关 | 作用 | 关掉的后果 |
|---|---|---|
TSOEnabled | 总开关，控制原子操作的内存序语义 | 多线程程序随机出错，难以定位 |
VectorTSOEnabled | 向量化的 TSO 实现，批量处理屏障 | 性能下降，正确性不受影响 |
HalfBarrierTSOEnabled | 半屏障优化，用单向屏障替代全屏障 | 极少数场景下语义可能不够严格 |
实测经验：单线程为主的程序，可以试着把TSOEnabled关掉，性能提升很明显，尤其是那种大量做内存分配的负载；多线程程序别碰这个开关，除非你确认那个程序在 ARM 上自己就处理了内存序问题（这种情况很少）。VectorTSOEnabled和HalfBarrierTSOEnabled是纯优化，除非遇到具体的正确性问题，否则保持默认开着。
判断程序是不是吃 TSO 的亏，有个简单的办法：先默认配置跑一遍，用time记录；关掉 TSO 再跑一遍对比。差距超过 30% 且程序确实是单线程，就关；差距不大就留着，省心。
4.2 SMC 检测与代码缓存
自修改代码这件事在 JIT 里是个硬问题。x86 程序往某块内存写了新指令，然后跳过去执行——翻译器必须知道那块内存的内容变了，之前翻译好的代码缓存失效。ARM 上做这件事的常规方案是给代码页加写保护，写了就陷进信号处理器。
代价是：如果程序频繁往代码页写（加壳、部分加密校验、某些老式运行时），就会不断触发信号，每次都要走一遍“失效缓存、重新翻译”的流程，卡顿感非常明显。
调优的方向有两个。一是降低检测精度，只在特定时机（比如mprotect调用）做缓存失效，牺牲极端情况下的正确性换流畅度。二是让程序别这么干，比如某些加壳软件关掉保护壳再跑。
这块没有万能参数，得看程序行为。一个判断方法：跑的时候观察 CPU 占用，如果strace里看到大量SIGSEGV相关的信号投递，基本就是 SMC 在反复触发。
4.3 图形栈 thunk 的配套条件
thunk 的本意是“别模拟，直接用宿主的”。这个设计对性能极友好，但对环境一致性要求很高。
宿主这边必须装好 ARM64 版本的原生库：libgl1、libglx-mesa0、libvulkan1、驱动对应的 ICD 文件、libasound2、Wayland 或 X11 的客户端库。装不全会出现两类报错：一类是客户机程序自己报“display 连接失败”，另一类是 FEX 在转发阶段报“thunk library not found”。
有个细节容易被忽略：宿主和客户的库版本不需要严格一致，但主版本号不能差太多。比如客户程序的 libGL 是 Mesa 高版本，宿主装的是老得多的版本，某些扩展函数的符号在宿主库里不存在，thunk 找不到符号就会退化成失败。遇到这种情况，要么把宿主库升级，要么换一个更老的 RootFS。
分辨率、缩放这类设置也在这一层。宿主是 Wayland 会话的话，客户程序的窗口缩放有时候会异常，因为 thunk 传递的是宿主的分辨率信息。解决方式通常是在客户程序里手动指定窗口大小，或者调整宿主合成器的缩放策略。
4.4 x87 与现代 SIMD 的精度取舍
x86 的浮点历史包袱很重。x87 单元用 80 位扩展精度，早期大量程序依赖这个精度做数值计算；ARM 这边只有 64 位 double，直接对应会造成精度损失。
FEX 提供的折中是：默认精确模拟 x87 的 80 位行为（用软件多字位运算），性能差；开启X87ReducedPrecision之后用 64 位直接算，快但结果可能对不上。
什么时候该开？我的判断标准是：如果程序做的是图形渲染、物理模拟、游戏这类对精度不敏感的负载，开。如果程序做的是科学计算、财务、需要和真机结果严格比对的东西，别开。中间地带就先不开跑一遍，觉得慢再开，然后对比关键输出有没有差异。
现代程序基本用 SSE 和 AVX 做浮点，x87 只在很老的代码里出现。所以这个开关对多数新软件其实是无效的——了解它的存在，遇到老程序再想起来就行。
提示：
MemcpySettings这个选项容易被忽略但影响不小。它控制 FEX 对memcpy类操作的实现选择，不同设置在不同负载上差几十个百分点。默认值通常是稳妥的选择，只有在明确知道程序大量做大块内存拷贝时，才值得逐个试过去。
5. 常见故障排查实录
5.1 启动阶段就挂掉
这一类最典型的报错是“找不到动态链接器”或者“无法加载共享库”。根因基本锁定在 RootFS 上。
排查顺序：先确认RootFSPath指向的目录真实存在且可读；再看lib64/ld-linux-x86-64.so.2在不在；然后用file确认这个链接器确实是 x86-64 的 ELF，不是误拷的 ARM 版本；最后看程序自身依赖的库在 RootFS 里有没有。
# 在 FEXBash 里执行，列出程序依赖的所有库 ldd /path/to/program | grep -i "not found"not found的那些就是要补的。补的方法不是往宿主装（宿主装的是 ARM 版本，没用），而是在 RootFS 里装。
另一类启动失败是“权限被拒绝”。RootFS 是从别处拷来的话，文件所有者可能不对。给 RootFS 目录做一次归属修正，把它改成当前用户，或者干脆用sudo跑——但用 root 跑有安全风险，能不用尽量不用。
还有一类比较隐蔽：程序启动后立刻Segmentation fault，没有任何输出。这种时候打开 FEX 的日志输出，看最后一条翻译记录落在哪条指令上。日志很啰嗦，但它是唯一能看到翻译细节的手段。
FEX_OUTPUTLOG=1 FEX_SILENTLOG=0 FEXLoader /path/to/program 2>&1 | tail -505.2 图形和音频问题
窗口能开但黑屏、或者开着开着崩掉，先分清是渲染问题还是 thunk 问题。
黑屏但程序没崩，通常是宿主侧的 GL 上下文创建失败或者渲染到了错误的 surface。先在宿主上确认 GL 本身是好的：glxinfo -B（X11）或者wayland-info看一眼。宿主自己都画不出东西，别指望 thunk 能成。
程序启动时报某个 GL 函数找不到符号，是宿主库版本不匹配。用ldconfig -p在宿主上查那个库，看有没有对应的扩展符号。
音频问题更简单粗暴：宿主没装libasound2:arm64就没声音，装了但没配默认设备会静音。在宿主上用aplay -l确认设备存在，再进 FEXBash 里测。
5.3 性能异常与卡顿
“能跑但卡”的原因有好几层，按这个顺序排查效率最高。
先看是不是 TSO 的问题，方法前面讲过——关掉对比。再看是不是 SMC 反复触发，观察信号和 CPU 的异常占用。然后看图形是不是走了软件渲染而不是硬件加速，glxinfo在客户环境里查渲染器名字，出现llvmpipe之类的字样就说明没吃到 GPU。最后看是不是内存不够导致的换页，free -h和vmstat 1一起看。
卡顿呈现周期性、每隔几秒来一次的那种，多半是文件系统相关：RootFS 放在慢速存储上，程序频繁读库文件。把 RootFS 挪到 SSD 或者 tmpfs 里能明显改善。
5.4 排查速查表
| 现象 | 最可能的原因 | 处置动作 |
|---|---|---|
Exec format error | 内核没接管，没走 FEX | 用加载器显式启动，或检查 binfmt 注册 |
找不到ld-linux-x86-64.so.2 | RootFS 路径错或未解压完整 | 校验 RootFSPath 与关键文件 |
| 启动后立刻段错误 | 指令不兼容或 SMC 处理异常 | 开日志看最后翻译的指令 |
| 窗口黑屏 | 宿主 GL 上下文失败 | 宿主上验证 GL，检查 ICED 文件 |
| 多线程程序随机崩溃 | 内存序没模拟到位 | 确认TSOEnabled未被误关 |
| 性能周期性抖动 | 代码缓存频繁失效 | 调整 SMC 检测策略 |
| 有画面无声音 | 宿主缺音频库或设备 | 宿主aplay -l验证 |
| 拷贝 RootFS 后跑不起来 | 软链接断裂或权限位丢失 | 用tar -p重新打包 |
6. 几条踩过坑之后才明白的经验
别把 RootFS 和环境绑太死。我一开始图省事，把 RootFS 放在用户主目录下，结果做系统迁移的时候漏掉了，所有配置全部重来。后来改成放在独立分区的一个固定路径，Config.json里写绝对路径，迁移只需要改一个字段。RootFS 的体积不小，也别指望备份工具会顺手带它。
环境变量比配置文件好用，但别混着用。调试的时候我喜欢用FEX_前缀的环境变量临时覆盖配置，改一行就能试一个参数，比反复编辑 JSON 快。但试完一定要清掉，不然过几天你会忘了自己设过什么，然后对着“为什么配置改了没效果”抓头发。我的做法是：临时调试写进一个source的脚本里，会话结束就没了。
性能优化的收益递减得非常快。头两个小时的调优能把一个跑不动的程序拉到能用，后面再花二十个小时可能只多挤出百分之十。真正卡住的时候，换个思路往往更划算——比如换个更轻量的替代软件，或者干脆找台 x86 机器跑那几个重活。翻译层是扩大可用范围的工具，不是逼着你把所有东西都在 ARM 上跑的理由。
遇到疑难问题先看上游的 issue 和文档。FEX 的迭代速度很快，很多你遇到的问题在半年前就被修了，或者有明确的规避方案。配置文件格式在版本之间变过好几次，网上抄来的旧配置直接套用会出各种费解的错，对不上就以你机器上生成的默认为准。
最后分享一个小技巧：如果你只想验证某个 x86 程序能不能跑，不想在 RootFS 上折腾太多，可以用一个最小化的 base rootfs（不带桌面、不带编译器），装完程序所需的运行库就停手。这种精简环境启动快、出问题好定位，验证完了再决定要不要给它配一套完整环境。
