嵌入式Linux上的.NET 10 Native AOT：从交叉编译到网关部署全记录

三年前我接了一个边缘采集网关的选型评估，硬件是某ARM Cortex-A53工业级板卡，存储和内存都只有512MB，原计划用C++。当时这事儿在团队里争议不小，因为.NET在这个场景几乎算禁忌——传统方式把.NET runtime塞进去就要占上百MB，启动还要JIT预热识别托管入口，嵌入式设备根本扛不住。直到我开始动手尝试.NET 10 Native AOT，这个局面才彻底改观：发布产物变成一个十几MB的原生Linux可执行文件，目标板不需要装任何运行时，首启时间从“喝杯水再看”变成“按完回车就有响应”。这篇文章不打算泛泛介绍AOT特性，而是把我最近在一个数据采集网关项目里从写代码、搭交叉编译环境，到部署上板、接GPIO和串口、调性能、排坑的全过程记录下来。适合正在评估.NET做嵌入式、又担心交付复杂度和运行性能的团队参考。

1. 为什么偏要在嵌入式Linux上跑.NET，而不是换C或Go

1.1 过去的.NET在嵌入式设备上有多尴尬

五年前如果有人跟我说在嵌入式Linux上用.NET做生产级服务，我大概率会摇头。原因很直接：当时主流的.NET Framework本身就不跨平台，到了.NET Core才画了个跨平台的大饼，但运行时依赖依然是个绕不开的坎——你要么在目标板上预装对应版本的.NET runtime，要么用自包含发布方式把整个运行时打包进应用目录。前者要求设备环境可控，后者直接把单文件体积推到七八十甚至上百MB。对一台只有512MB存储、还要装系统跑业务的板卡来说，光是这份运行时开销就够让人肉疼。

更头疼的是启动延迟。嵌入式设备的开机画面动辄要欢迎用户，工业设备倒不用看画面，但采集服务启动太慢会直接影响上电到正常出数的时间。传统模式下首次执行要做JIT编译，托管方法边执行边生成机器码，第一次调用某个冷门路径往往要卡一下。虽说后来有了ReadyToRun（R2R）预编译方式，能缩短一部分JIT时间，可它本质还是带着整个运行时跑，体积问题没有解决，还增加了预编译镜像的维护成本。在需要长时间无人值守、存储焊死、断电重启频繁的工业场景里，这些都是实打实的坑。

我接手的这个网关项目，最初方案就是C++。理由也很朴素：原生二进制、体积小、好部署，业界在嵌入式领域积累了大量库。但这套方案到我这边推进了两周，就明显体会到开发效率的差距——同事实测调一个JSON字段映射加断线重试逻辑，C++下要自己管内存、处理编译宏、维护构建脚本，算上调试时间要接近一天；同样的逻辑放在C#里，用现成的库加类型安全代码，个把小时就能跑通单测。团队里几位主力都是C#出身，硬切C++等于把产品周期和人员门槛都拉高了。

1.2 Native AOT改变了哪些事情

.NET 10的Native AOT（Ahead-Of-Time compilation，提前编译）解决的核心问题，就是把“托管应用”变成一个真正的原生程序。它不是像R2R那样预先生成部分机器码然后仍然依赖运行时，而是通过ILC（IL编译器）把程序集、运行时中需要的部分、以及你引用的库，一起静态链接成一个独立的原生可执行文件。这意味着目标机器上不需要安装.NET运行时，甚至理论上可以不需要额外的CLR宿主进程，跑起来就是一个普通Linux进程。

这个机制带来三个很直观的变化。第一个是体积：以我们的网关程序为例，自包含发布加裁剪，体积能到80MB上下；换成Native AOT之后，最终二进制只剩11MB左右。原因是AOT模式把运行时里用不到的部分直接丢弃，只保留确切需要的GC、异常处理和类型系统骨架。第二个是启动时间：没有JIT预热，程序入口直接执行机器码，实测冷启动（从进程fork到进入Main函数完成初始化）从原来的2秒多降到120ms级别，对无人值守设备来说，这个差距意味着上电后采集服务能更快就位。第三个是部署复杂度：交付物就是单个可执行文件加少量依赖数据文件，拷进板子就能跑，不用跟运行时版本较劲。

当然，后面我会仔细讲，AOT不是免费的午餐。它牺牲的是动态性——反射受限、动态加载基本告别、某些依赖运行时服务的库必须换实现方式。但在嵌入式场景里，我们本身就不需要那么多动态能力，需要的恰恰是确定性。所以对于固定的、行为可预见的采集和控制程序，AOT的哲学天然契合。

1.3 选型背后的业务逻辑

说到业务逻辑，真正让我下定决心用.NET 10 AOT的，不是技术指标有多好看，而是“团队能持续交付”这个现实问题。我们团队的主力栈是C#，从后端服务到边缘计算节点，统一用同一套语言和开发习惯，意味着：

• 同一套业务代码可以同时跑在服务器和嵌入式设备上，逻辑保持高度一致；
• 网关上的采集处理代码，可以直接复用后端已经在用的协议解析库、序列化库、配置管理组件；
• 新同学入职只需要了解AOT发布方面的限制，不需要为了嵌入式单独学一套C/C++工程体系。

还有一个容易被低估的理由：内存安全。C++在嵌入式里威力很大，但手写内存管理带来的野指针和缓冲区溢出风险，在无人值守设备上排查成本极高。C#在AOT模式下托管堆和GC仍然生效，虽然牺牲了一点极致性能，却换来了远超C/C++的稳定性。比如在串口解析场景里，字节数组解析、结构体变换、异常边界处理，C#写出来很难弄出段错误，这在后期维护阶段价值巨大。

至于Go，确实是嵌入式领域一个热门选项，交叉编译也方便。但Go的运行时（goroutine调度、GC）同样会打进二进制，启动速度虽然不错，最终静态二进制在部分场景下体积还是比C语言大，而且如果你对C#生态更熟悉，迁移成本并不低。我不打算把话说绝对，但在我们的网络协议栈、规则引擎、云连接这些组件都是C#实现的背景下，继续用C#是性价比最高的路。

2. 交叉编译环境：从Windows开发机到ARM Linux目标板

2.1 目标板与工具链选型

这次的网关硬件是基于某ARM Cortex-A53四核方案的工业控制板，跑的操作系统是带glibc的嵌入式Linux（buildroot构建），libc版本2.31，内核5.10。选择A53而不是更高端的A72或A78，主要考虑功耗和成本，但这意味着CPU算力并不宽裕，AOT预编译反而适合它——运行时越省，留给业务逻辑的算力越多。

交叉编译环境这块，我一开始走了一点弯路。最先尝试的是直接在Windows开发机上装.NET SDK，然后dotnet publish -r linux-arm64，以为一条命令就万事大吉。结果Native AOT在Linux目标上需要一个完整的交叉编译工具链，否则ILC后端无法把托管代码和本机代码链接成最终ELF。官方文档推荐的AOT工具链依赖是clang、lld、zlib，以及和你目标系统匹配的系统库。所以我的最终环境是这样搭的：

• 开发机：Windows 11 + WSL2（Ubuntu 22.04），其实直接用Linux虚拟机也行，关键是方便安装交叉工具链；
• .NET SDK：10.0.x版本（当前稳定版），同时安装dotnet-sdk-10.0AOT相关组件；
• LLVM/clang：版本17或更高，AOT需要用它来生成和链接目标代码；
• 交叉编译器：这里我用的是gcc-aarch64-linux-gnu，配合目标板对应的sysroot。

这里有个选型要点：如果你目标板用的musl libc（比如Alpine系统），那最好直接发布linux-musl-arm64，交叉工具链也可以用musl-gcc。我们板子用的glibc，所以RuntimeIdentifier选linux-arm64。glibc的兼容性问题我在下一节会详细讲，这里先记住：AOT的目标产物依赖目标系统libc版本，编译环境的libc最好别比目标环境新太多。

2.2 sysroot和目标文件系统

交叉编译最容易被忽略的就是sysroot。所谓sysroot，就是目标板根文件系统的一份拷贝，里面包含了目标系统上/usr/lib、/lib下的动态库、链接器等。Native AOT在链接阶段需要知道目标平台上有哪些原生依赖符号、版本是多少，它不能直接用开发机的/usr/lib，因为那是x86_64的库，而且即使同样是ARM，板子的库版本和桌面Linux的库版本也未必一致。

我一开始偷懒，想着“反正AOT是静态编译，目标平台系统库我随便给一个差不多版本的就行”，结果在链接阶段报了一堆undefined reference和版本符号找不到的错误。后来学乖了：把buildroot生成的整个rootfs拷贝到开发机，路径比如/opt/sysroots/aarch64-glibc-rootfs，然后通过环境变量或csproj参数指定给编译链接器使用。具体做法是在csproj里设置SysRoot参数，再加几个必要的链接器参数，后面给配置代码。

2.3 最小的AOT发布配置

一个最小可跑通的csproj配置长这样：

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net10.0</TargetFramework> <RuntimeIdentifier>linux-arm64</RuntimeIdentifier> <PublishAot>true</PublishAot> <StripSymbols>true</StripSymbols> <OptimizationPreference>Size</OptimizationPreference> <InvariantGlobalization>true</InvariantGlobalization> <IlcGenerateCompleteTypeMetadata>false</IlcGenerateCompleteTypeMetadata> </PropertyGroup> <PropertyGroup Condition="Exists('/opt/sysroots/aarch64-glibc-rootfs')"> <SysRoot>/opt/sysroots/aarch64-glibc-rootfs</SysRoot> </PropertyGroup> </Project>

几个属性说明一下：

• PublishAot是总开关，置true后dotnet publish就会走AOT编译路径；
• StripSymbols去掉调试符号，体积能再小一圈，代价是以后抓不到C#层堆栈的符号信息，用dotnet-stack等工具分析崩溃会麻烦一些；
• OptimizationPreference支持Size和Speed二选一。嵌入式存储紧张，我压成Size，实测体积少1MB多，但部分循环密集代码慢了5%左右。采集类任务IO阻塞为主，CPU密集不多，所以体积优先更划算；
• InvariantGlobalization强制使用不变文化，会禁用ICU/全球化数据，体积能省下好几十MB。代价是DateTime.ToString、CultureInfo等格式化行为固定为英文数字格式，后面做日志要注意统一格式；
• IlcGenerateCompleteTypeMetadata控制反射元数据生成程度。设false是为了激进裁剪反射元数据，代价是动态反射的代码路径基本不可用，这点后面第6节详聊。

发布命令就一条：

dotnet publish -c Release -r linux-arm64 -p:PublishAot=true -o ./publish/arm64

发布完成后看下产物：

file ./publish/arm64/gateway # 输出类似：ELF 64-bit LSB executable, ARM aarch64, statically linked

注意这里看到的是statically linked指的是托管运行时部分静态链接进二进制，但程序仍然可能动态链接目标系统的libc等原生库。要确认动态依赖，用ldd或readelf -d查看：

readelf -d ./publish/arm64/gateway | grep NEEDED

如果输出里有libc.so.6、libgcc_s.so.1这些，说明部署时目标板系统必须提供这些库。这点极其重要，很多第一次碰AOT的人会误以为“全静态了什么都不用管”，结果拷到板子上一跑就报找不到共享库。

3. 板子上的部署与首轮运行

3.1 拷贝、权限和启动参数

发布产物准备妥当后，我用scp把整个arm64目录拷到板子的/opt/gateway/下。拷贝时有个小经验：目录权限和文件属主最好和运行时用户匹配，我习惯建一个专用的服务账户，而不是直接用root跑。原因不复杂——采集服务要读设备节点、写日志，权限太大会增加风险，而且在无人值守设备上，一旦程序有漏洞，攻击面也会被压缩。

首次运行前，记得做三件事：

chmod +x /opt/gateway/gateway mkdir -p /var/log/gateway chown serviceuser:serviceuser /opt/gateway/ -R

启动试试：

sudo -u serviceuser /opt/gateway/gateway --config=/etc/gateway/config.json

如果一切顺利，日志里会出现启动提示和第一行采集输出。但真实情况是——我第一次跑它直接崩了，错误信息是：

./gateway: /lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found

3.2 第一个大坑：glibc版本不匹配

这就是我前面反复强调的libc兼容性问题。原因很简单：开发机上WSL2（Ubuntu 22.04）的glibc是2.35，而目标板buildroot的glibc是2.31。AOT在链接时把开发环境识别到的glibc符号版本要求记录进了二进制的.gnu.version_r段，运行时就要求目标系统提供不低于2.34的符号版本，板子上的老glibc自然满足不了。

这个坑绕开方式有几种，按推荐排序：

1. 用和目标板一致版本glibc的sysroot做交叉编译。也就是把buildroot的rootfs挂上来，SysRoot指向正确目录后，链接器会按sysroot里的libc版本选择符号版本。这是最干净、最不易出问题的做法；
2. 在Docker里跑一个和目标板libc版本接近的Linux发行版容器（比如Debian bullseye是glibc 2.31），在容器内做发布。这样生成的二进制符号版本就是2.31或更低；
3. 如果实在没条件，可以试试用linux-musl-arm64发布，musl静态链接后能做到真正无动态依赖，但这要求所有NuGet原生依赖都能支持musl环境，并不总成立。

我当时选了方案1，把buildroot的rootfs挂到/opt/sysroots/aarch64-glibc-rootfs，重新发布后readelf检查符号版本，确认最高要求是GLIBC_2.31，拷到板子上一跑就过了。

3.3 用systemd托管，让服务随开机自启

无人值守设备上，程序不能指望有人登录后手动敲命令。用systemd unit文件托管最合适。我的/etc/systemd/system/gateway.service配置大致如下：

[Unit] Description=Data Collection Gateway After=network.target [Service] Type=simple User=serviceuser WorkingDirectory=/opt/gateway ExecStart=/opt/gateway/gateway --config=/etc/gateway/config.json Restart=always RestartSec=5 Environment=DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 LimitNOFILE=65536 [Install] WantedBy=multi-user.target

几个细节值得注意：

• Type=simple适用于前台长驻进程，systemd不需要程序主动通知就绪，直接认为进程起来就是服务启动；
• Restart=always配RestartSec=5，崩溃后5秒自动拉起。AOT程序本身没有托管运行时看护，进程一挂就是真的挂了，所以外部守护必须做好；
• LimitNOFILE一定要调大。很多网关设备要同时打开几十个TCP连接加串口设备，默认1024很容易触发“Too many open files”；
• Environment里再次声明全球化不变模式，双保险，避免代码里某个环节改了预设文化造成格式化差异；
• 因为可执行文件是静态自包含的，不需要额外指定LD_LIBRARY_PATH，这也算AOT的一个省心点。

启动服务并检查状态：

systemctl daemon-reload systemctl enable gateway systemctl start gateway systemctl status gateway journalctl -u gateway -f

这一套下来，程序就具备了工业设备该有的基本自治能力：开机自启、崩溃重启、日志可查。

4. 设备交互层：GPIO与串口这样接入

4.1 选择直接操作还是依赖现有库

嵌入式设备绕不开和外设打交道。这个网关上有两路串口（接传感器）、一路RS485（接电表）、若干GPIO（做输入检测和继电器输出）。在.NET里访问这些外设有几条路：

• 直接读写Linux设备文件，比如/sys/class/gpio/gpioX/value、/dev/ttyS0。好处是零依赖、逻辑透明，但性能一般，而且GPIO sysfs接口新内核里已经标记为deprecated，新项目最好用libgpiod接口；
• P/Invoke封装libgpiod、termios等C库函数。这是最正统、性能最好的路子，AOT下完全可行，代价是要自己处理结构体布局和错误码；
• 用第三方NuGet包，比如某些IoT库。但要小心：NuGet生态里的硬件库很多是老.NET Framework时代产物，有些依赖反射或动态加载，在AOT下可能直接编译不过；还有一部分包会通过RuntimeInformation动态判断平台，裁剪后会丢失分支。我建议坚固的场景还是自己封装一层。

因为我只需要GPIO几路点位的读写和串口/RS485的收发，最后选择了P/Invoke方案。这样即使将来换内核或换板卡，只要Linux接口不变，代码就能复用。

4.2 AOT下的P/Invoke注意事项

AOT模式下的P/Invoke和传统托管运行时有几个显著差异。最需要注意的是封送方式——传统DllImport默认支持字符串封送、结构体自动布局等便利特性，但在AOT里（尤其开启完整类型元数据裁剪后），这些便利会被收紧。我建议遵循这几条经验：

1. 能传指针就不要传对象。比如read、write接口，直接传byte*或IntPtr，避免数组自动封送的隐式拷贝；
2. 结构体布局明确写[StructLayout(LayoutKind.Sequential, Pack = 1)]，不要依赖默认对齐。termios、gpiod这些C结构体本质是二进制协议，对齐错了数据就全错；
3. 所有外部函数用[LibraryImport]而不是[DllImport]。LibraryImport是.NET 7引入的源生成器方案，编译期生成封送代码，不依赖运行时反射，是AOT下的标准做法；
4. 加载原生库路径要绝对明确。如果用dlopen，AOT下DllImport的解析行为和传统略有差异，一定要指定绝对路径或确认系统的动态库搜索路径包含所需库。

4.3 GPIO输出控制的一个实操片段

以libgpiod读取一路输入为例，我用LibraryImport封装了两个函数：

[LibraryImport("libgpiod.so.2")] internal static partial IntPtr gpiod_chip_open(string name); [LibraryImport("libgpiod.so.2")] internal static partial int gpiod_line_request_input(IntPtr line, string consumer, int requestType);

然后封装一个读输入电平方法：

public int ReadInputPin(int offset) { IntPtr chip = gpiod_chip_open("/dev/gpiochip0"); if (chip == IntPtr.Zero) throw new IOException("gpiod_chip_open failed"); try { IntPtr line = gpiod_chip_get_line(chip, offset); int ret = gpiod_line_request_input(line, "gateway", 0); if (ret < 0) throw new IOException($"request input failed, errno={ret}"); return gpiod_line_get_value(line); } finally { gpiod_chip_close(chip); } }

这里有几个经验点：

• 我选择在每次读写时打开并关闭chip，而不是常驻句柄。虽然性能略低，但避免了长时间运行后内核句柄泄漏问题。如果你对性能敏感，可以改成单例持有chip和line的句柄，并做好进程退出时的清理；
• 所有错误码要即刻检查。Linux设备驱动函数出错时通常返回负的errno，直接用返回值判断即可；
• 字符串参数在LibraryImport中默认按UTF-8封送，这里传设备路径和consumer名没有问题。但如果库要求特定的编码，就需要自己转成byte*再传。

4.4 串口和RS485的收发封装

串口这块，我用的是标准termios接口。最核心的就是open、tcgetattr、tcsetattr、read、write这几个函数。封装好后逻辑很直观：打开/dev/ttyS1，设置波特率（比如115200）、8N1、无流控，然后循环读取。

一个在.NET里容易踩的细节是：FileStream和SerialPort这些托管封装尽量别用，因为它们内部走的是托管IO调度，到AOT下有时会引入不必要的缓冲和线程开销。直接P/Invokeopen拿fd，再用posix_read、posix_write阻塞读写，行为最可控：

[LibraryImport("libc.so.6", SetLastError = true)] internal static partial int open(string path, int flags, int mode); [LibraryImport("libc.so.6")] internal static partial nint read(int fd, byte[] buffer, nint count); [LibraryImport("libc.so.6")] internal static partial nint write(int fd, byte[] buffer, nint count);

这里有个小坑：read和write在某次软硬件调试中经常一次没读完，或一次没写完。按POSIX约定，必须循环处理返回值和剩余长度。我写了个简单辅助函数处理部分读写：

private static int ReadFull(int fd, byte[] buf) { int offset = 0; while (offset < buf.Length) { nint n = read(fd, buf.AsSpan(offset).ToArray(), buf.Length - offset); if (n <= 0) return offset; offset += (int)n; } return offset; }

注意我为了示例简洁把Span转成了数组，实际生产代码里应该用固定缓冲池加unsafe指针操作，避免每一次read都分配新数组增加GC压力。

5. 启动速度、内存和数据采集的实测表现

5.1 和传统自包含发布方式对比

同样的业务代码、同样的板子，我分别用“自包含+裁剪”发布和“Native AOT”发布做了一个对比。测试条件：冷启动计时从进程创建到主循环打印第一条日志；内存按稳定运行10分钟后的RSS计算；存储按发布产物目录总大小计算。

这个数字非常直观地解释了我为什么力推AOT方案。特别是512MB内存的板子上，省出来的100MB内存可以用来做更大的数据缓存和消息队列缓冲，这在采集频次上来之后尤为重要。

5.2 无值守运行的内存表现

很多嵌入式团队担心托管运行时在长期运行下有内存缓慢上涨的问题。我特意把网关放在测试台架上连续跑了7天，每天采集约200万条数据点，每30秒落盘一次数据文件。观察到的RSS曲线整体平稳，从第1天的35MB到第7天约38MB，涨幅在历史日志和对象池正常抖动范围内。Native AOT的GC用的是随二进制编译进出的GC实现，行为相对一致，没有出现传统JIT时代偶发的内存碎片化问题。

不过有一个值得注意的点：AOT模式下GC的触发策略默认是workstation模式（工作站模式），并发后台GC在部分高吞吐场景下可能表现不如server模式。如果数据采集中转用多了大数组，可以在启动前通过环境变量配置GC模式。我自己的实践是保持默认，因为这板子IO型采集为主，托管分配集中在小块缓冲区上，GC压力不大。

5.3 采集链路的实测数据

以RS485读电表数据为例，测试环境是9600bps、8E1，每200ms轮询一次电表返回32字节数据。AOT版本的CPU占用率稳定在3%-5%之间（四核A53整体负载），串口数据解析加JSON序列化后经MQTT上报，单条链路延迟在20ms以内。相比之前评估的C++方案，性能差距可以忽略，而开发维护成本低了不止一个档次。

还有一个细节想分享：GC暂停对串口缓冲区来说可能导致读取间隙。我的处理办法是串口接收线程用高优先级，同时读缓冲设大些，让GC暂停期间数据先在内核缓冲区排队，恢复后再一起读走。实际调优后，9600bps速率下没有任何丢包。

5.4 多路采集场景的调度思考

网关上面的传感器不只一路，串口、RS485、GPIO中断可能同时到达。我起初用一个线程轮询所有外设，代码简单但响应优先级不好控制。后来改成每类设备一个专用线程，配一个轻量线程安全消息队列把数据汇聚到主处理线程。这个设计得益于C#的Channel<T>类型，既不依赖反射，AOT下也没问题，非常适合嵌入式多源采集。

6. 必须提前知晓的五个AOT边界坑

6.1 反射和动态代理：源头就该绕开

AOT下第一号禁忌是随意反射。typeof(Foo).GetMethod(...)、Activator.CreateInstance(...)这类代码，在传统.NET里稀松平常，但AOT编译器不知道你要反射什么类型，它只能把编译时可见的元数据留下，动态获取的成员往往直接返回null或抛异常。

像JSON序列化，我马上把System.Text.Json的反射模式换成了源生成器模式。具体做法是定义一个JsonSerializerContext：

[JsonSerializable(typeof(TelemetryPacket))] [JsonSerializable(typeof(DeviceConfig))] internal partial class GatewayJsonContext : JsonSerializerContext { }

然后在调用处直接JsonSerializer.Serialize(packet, GatewayJsonContext.Default.TelemetryPacket)。这样序列化代码在编译期就生成，完全没有反射。配置管理里如果需要动态绑定，也用源生成器而非ConfigurationBinder的反射路径。这种做法不仅在AOT下跑得通，性能还比反射快不少。

6.2 动态加载：插件化思路必须调整

传统.NET服务可能用Assembly.LoadFrom实现插件机制，AOT模式下这条路是死的。因为运行时没有能力在编译后再解释执行新程序集，程序集都是预先编译进二进制的。我项目里原本有个“按设备型号加载不同协议插件”的设计，后来改成静态订阅：

把所有协议类注册到一个字典里，编译期硬编码：

var handlers = new Dictionary<string, IProtocolHandler> { ["modbus"] = new ModbusHandler(), ["dlms"] = new DlmsHandler(), };

这样虽然牺牲了“放一个dll就支持新协议”的动态性，但换来的是启动时确定所有路径可用、不会被裁剪器干掉。对量产设备来说，固件更新本来就该走整包升级，而不是靠加载第三方dll，所以这个限制完全可以接受。

6.3 NuGet包里的原生库依赖

AOT发布时，NuGet包里如果有runtimes/linux-arm64/native/*.so这类原生库文件，SDK通常会自动识别并拷贝到输出目录。但有两个坑：

一是有些包的native目录同时含有x64和arm64版本，如果csproj里RuntimeIdentifier没写对，拷贝可能拿错架构的库，运行时报错却提示找不到符号。检查方法很简单：看发布产物目录里*.so的文件架构：

file /opt/gateway/*.so

二是有些库用了dlopen或GetProcAddress动态查找符号，而不是在ELF里标明依赖，这种库在AOT下很难静态链接进去，通常只能保持动态依赖，并保证目标系统上有对应so文件。如果你的部署环境不允许额外放置so文件，那就要对NuGet依赖做一次原生库梳理，尽量选择纯托管实现或支持AOT的库。

6.4 全球化数据和ICU裁剪的双刃剑

我把InvariantGlobalization设为true后，程序无法使用ICU的全球化数据，这意味着CultureInfo基本失效，字符串比较永远是序号方式，日期格式化固定为不变文化格式。这在纯英文日志和设备通讯场景里没任何问题，甚至性能更好。但如果你需要处理中文、阿拉伯文等特殊文化格式（比如按本地习惯显示日期、排序），那就要权衡：要么保留ICU相关数据增大体积，要么自己写一套格式化逻辑。我们日志统一用ISO 8601时间戳，所以完全没影响。

另一个相关问题是字符编码。Encoding.GetEncoding("GB2312")这类代码在裁剪模式下一定别用——编码提供程序依赖反射注册。需要支持中文编码时，要么引包System.Text.Encoding.CodePages并显式RegisterProvider，要么提前把所有数据转成UTF-8。我们的电表协议里要解析ASCII码数字，直接用byte操作就够了。

6.5 异常路径和代码体积的平衡术

AOT裁剪器在决定保留哪些代码时，会分析类型引用关系。如果程序里到处是try-catch且每个catch都堆了一堆调试日志，裁剪器会把相关代码都保留，体积会明显变大。我在开启OptimizationPreference=Size后发现，热路径异常处理写太细会让二进制比预期大不少。

我的经验是把异常逻辑分层：

• 外部IO边界（串口、网络、设备文件）做好错误码返回，不要上来就抛异常；
• 内部业务逻辑的异常只保留关键路径的catch，让上层统一处理；
• 日志输出用轻量封装，避免在每个catch里拼接大字符串。

最终二进制从14MB压回11MB，运行时的行为并没有变差，反而因为减少无谓异常路径，CPU占用更稳定了。

6.6 配合“动态依赖检查”的部署前清单

最后分享一个我每次发版前都会走的检查清单。不要等到拷到板子上了才发现问题，在开发机上提前验证能省大量调试时间：

1. dotnet publish成功后，用file检查产物架构是否为ARM aarch64；
2. 用readelf -d列出NEEDED依赖，逐一确认目标板上确实有对应库，且版本不低于需求；
3. 将产物拷到和目标板同版本libc的容器（或板子）上实际跑一遍--version或冒烟测试命令；
4. 检查/etc/ld.so.cache里包含的库路径是否正确，尤其当程序依赖非标准路径下的原生库时，要在systemd unit里设置LD_LIBRARY_PATH；
5. 确认无特殊全局状态依赖，比如不需要在目标板上预置DOTNET_环境变量（InvariantGlobalization等属性在发布时已经固化）。

每一步都不复杂，但把这些合在一起，能避免我这次项目里遇到的所有首发问题。

写在最后的一点个人体会

在嵌入式Linux上用.NET 10 Native AOT做生产程序，已经从“能不能跑”进化到了“怎么跑得稳”。我在这个网关项目里最大的感受是：AOT真正把托管语言的开发效率和原生程序的部署体验结合到了一起。过去团队纠结的运行时体积、启动延迟、内存占用和依赖管理，在AOT模式下都有了清晰且可复用的解法。

当然也有代价。动态反射、插件化、全局化这些近乎“偷懒”的能力被拿掉了，你必须更早地思考类型边界、序列化方式和原生依赖。但换个角度看，这些思考在嵌入式开发里本就是必要的——C/C++开发者每天都在面对类似约束。对我来说，用C#写底层设备逻辑顺手程度远超预期，而AOT发布带来的单文件交付，让现场实施人员的部署动作从“解压、配环境、试运行、调环境变量”变成“拷一个文件、改一份配置、启动”。如果真的非要给后来者一句建议，那就是：趁早把反射和动态加载从代码里清除干净，第一个AOT版本越早编译出来，后面填坑的痛苦越少。