这是个很有意思的观察！我来帮你拆解下背后的几个核心原因：

1. 标准库与动态链接的隐性差异 #

Debian x86_64和Raspberry Pi OS aarch64默认使用的glibc实现，在动态链接细节上有不少区别：

• x86_64的glibc动态链接逻辑更紧凑，默认链接的libc.so中，printf这类常用函数的调用路径经过了高度优化，冗余代码极少。
• 而aarch64版本的glibc，为适配ARM架构的硬件特性（比如指针认证、堆栈安全防护），默认包含了更多安全校验代码，这些额外逻辑会直接增加二进制文件的大小。
• 你可以试试静态编译对比：gcc foo.c -static，此时两个平台的二进制大小差距会明显缩小，能直观看出动态链接带来的差异。

2. 指令集的代码密度差异 #

x86_64是变长指令集，常用指令（比如函数调用、返回、简单运算）的编码可以短到2-3字节；而ARM64是固定4字节的指令集，哪怕是最简单的操作也得占满4字节。比如一个printf的调用，x86_64可能只需要5字节，ARM64则必须用4字节指令加上额外的寄存器准备代码，累积下来整个代码段的大小自然会更大。

3. GCC默认编译选项的平台差异 #

不同平台的GCC默认配置不一样：

• Debian x86_64的GCC默认可能悄悄开启了-Os（优先优化尺寸）或者类似的轻量优化，而树莓派的GCC默认更偏向兼容性和基础性能，没有默认启用尺寸优化。你可以手动在两个平台都加上-Os参数编译，会发现aarch64的二进制大小会明显缩小，和x86_64的差距也会变小。
• 另外，ARM平台默认启用的安全编译选项（比如-fstack-protector-strong、-fPIE）的开销比x86_64更大，这些都会在可执行文件中增加额外的校验代码段。

4. 动态链接器启动代码的差异 #

x86_64的动态链接器ld-linux-x86-64.so.2的启动初始化代码非常精简，而aarch64的ld-linux-aarch64.so.1需要处理更多ARM架构特有的ELF加载逻辑（比如PLT/GOT表的处理方式、硬件寄存器的初始化），这部分启动代码会被嵌入到可执行文件中，进一步拉大了大小差距。

实际验证小技巧 #

你提到的Hello World程序，x86_64版本只有15KB左右，而aarch64版本有70KB，其中很大一部分差异来自动态链接器的启动代码、glibc的安全校验逻辑，以及ARM64固定长度指令带来的代码段膨胀。如果用-Os -s（优化尺寸+剥离符号）编译aarch64版本，大小会降到20KB左右，和x86_64的差距就小多了。

总的来说，这种差异是不同平台的指令集特性、编译器默认配置、标准库实现共同导致的，属于正常现象，不是编译错误。如果需要缩小aarch64的二进制文件大小，可以尝试开启-Os优化、调整安全选项，或者换用更轻量的标准库（比如musl）。

内容的提问来源于stack exchange，提问作者user31366153