一份面向前端 / 后端 / 客户端同学的分享文档：为什么同一个 C/C++/Rust 源程序，在 Windows、Linux、macOS 上编译出来的可执行文件互不通用？本文从文件格式、依赖加载、运行机制、权限模型四个层面拆解差异，并给出跨平台发布的实践建议。
一、为什么可执行文件不能跨平台
一个高级语言源文件（.c / .rs / .go 等）要变成能被操作系统执行的程序，必须经历编译 → 汇编 → 链接 三个阶段，最终产出的不是"机器码裸流"，而是一个符合目标操作系统加载器（Loader）约定的容器文件。
操作系统内核的可执行文件加载器是"专格式解析器"：
- Windows 内核只认 PE（Portable Executable）；
- Linux 内核只认 ELF（Executable and Linkable Format）；
- macOS / iOS 内核只认 Mach-O（Mach Object）。
因此，即使指令集（CPU 架构）相同（例如都是 x86-64），把 Linux 上编译出的 ELF 直接拷到 Windows 上也无法运行------不是 CPU 看不懂，而是加载器无法解析对方的容器格式。这就是跨平台需要分别编译（或借助兼容层）的根本原因。
关键区分：可执行文件是否通用，取决于两个维度 ------① 操作系统 ABI （文件格式 + 系统调用约定）；② CPU 指令集（x86-64 / ARM64 等）。二者必须同时匹配，缺一不可。
二、三大主流可执行文件格式
2.1 Windows：PE / PE32+
PE（Portable Executable）源自微软的 COFF 格式，是 Windows NT 系列的标准可执行格式，不仅用于 .exe，也用于 .dll、.sys（驱动）、.ocx 等。
结构特征：
- DOS MZ 头 ：文件开头是
4D 5A（"MZ"）魔术字，这是一段兼容老 DOS 的桩程序，现代系统仅用它识别格式。 - PE 签名 + COFF 头 ：偏移处有
PE\0\0签名，随后是机器类型、节数量等信息。 - 可选头（Optional Header） ：区分
PE32（32 位）与PE32+（64 位，Magic 为0x20B），记录入口地址、镜像基址、数据目录。 - 节表（Section Table） ：代码与数据按节组织，典型节包括
.text（代码）、.data（已初始化数据）、.rdata（只读数据）、.rsrc（资源）、.reloc（重定位）。
PE 的鲜明特点： 资源（图标、菜单、版本信息、字符串）被结构化地塞进 .rsrc 节，这是 Windows 图形界面程序的典型需求。
2.2 Linux / Unix：ELF
ELF 是 Unix System V 衍生出的开放标准，是 Linux、BSD 等系统的通用格式，一份文件可同时充当可执行文件、共享库（.so）、目标文件（.o） ，靠头部 e_type 字段区分。
结构特征：
- ELF Header ：开头是
7F 45 4C 46（"\x7FELF"）魔术字，标识文件类别、目标机器、入口地址等。 - 程序头表（Program Header Table） ：面向运行时加载 ，描述每个可加载段（Segment）如何映射进内存虚拟地址空间，是内核
execve加载的核心依据。 - 节头表（Section Header Table） ：面向链接与调试 ，描述
.text/.data/.bss/.symtab等节，供链接器和调试器使用。 - 严格区分 链接视图（Section） 与 执行视图（Segment）：链接期看节，运行期看段。
ELF 的鲜明特点： 段与节的分离设计、动态链接信息（.dynamic、.interp 指定动态链接器路径如 /lib64/ld-linux-x86-64.so.2）非常完备，是 Unix 生态"小而组合"哲学的体现。
2.3 macOS / iOS：Mach-O
Mach-O 继承自 NeXTSTEP 的 Mach 内核体系，是 Apple 全系平台的标准格式，同样兼顾可执行文件、动态库（.dylib）、Bundle、目标文件（.o）。
结构特征：
- Mach-O Header ：以
FE ED FA CE（32 位大端）等魔术字开头，记录 CPU 类型、子类型、加载命令数量。 - Load Commands（加载命令）：等价于 ELF 的程序头，逐条描述每个段/段内如何映射、动态库依赖、符号表位置等，是 dyld 加载程序的指令清单。
- Sections ：按 Segment（如
__TEXT、__DATA、__LINKEDIT）分组，段内再细分节。 - Fat Binary / Universal Binary：Apple 特有的"胖文件"，一个文件内打包多个架构（如 x86-64 + arm64），实现一份安装包同时兼容 Intel 与 Apple Silicon。
Mach-O 的鲜明特点： Universal Binary 的"多架构合一"、.dylib 动态库 + @rpath 路径解析机制，以及强制代码签名（详见第五节）是最具辨识度的差异点。
三、核心差异对比表
| 对比维度 | Windows (PE) | Linux (ELF) | macOS / iOS (Mach-O) |
|---|---|---|---|
| 文件魔术字 | 4D 5A（MZ） |
7F 45 4C 46（\x7FELF） |
FE ED FA CE / CA FE BA BE 等 |
| 可执行扩展名 | .exe |
无固定后缀（靠权限位 + 魔术字） | 无固定后缀 / .app Bundle 内二进制 |
| 动态库扩展名 | .dll |
.so |
.dylib / .framework |
| 静态库扩展名 | .lib |
.a |
.a |
| 目标文件扩展名 | .obj |
.o |
.o |
| 内存映射依据 | 可选头 + 数据目录 | 程序头表（Segment） | Load Commands |
| 入口 / 加载器 | 由 Loader 直接加载 | PT_INTERP 指定动态链接器 |
LC_LOAD_DYLINKER 指定 dyld |
| 动态库路径解析 | 搜索 PATH、应用目录、KnownDLLs | DT_RPATH/DT_RUNPATH、LD_LIBRARY_PATH |
@rpath/@loader_path/@executable_path |
| 多架构打包 | 一般单架构，靠安装包分发 | 单架构（fat 需额外工具） | Universal / Fat Binary 原生支持 |
| 代码签名 | Authenticode 数字签名 | 可选（内核模块常签名） | 强制（macOS Gatekeeper / iOS） |
| 典型工具链 | MSVC (cl/link)、MinGW、LLD | GNU Binutils (ld)、LLD | Apple clang + ld（ld-prime / ld64） |
四、依赖与加载机制的差异
4.1 动态链接库的查找路径
三种系统"怎么找到依赖库"的策略差异极大，是跨平台部署踩坑的重灾区：
- Windows ：按固定顺序搜索------应用程序所在目录 → 系统目录（System32）→ PATH 环境变量目录。
LoadLibrary是显式加载入口。问题：同名 DLL 容易被"劫持"，且系统库与应用库可能版本冲突（俗称 DLL Hell）。 - Linux ：可执行文件内嵌
DT_RUNPATH/DT_RPATH，再回退到/etc/ld.so.cache（由ldconfig生成），最后可用LD_LIBRARY_PATH临时覆盖。可通过ldd命令查看依赖清单。 - macOS ：使用
@rpath（运行时替换）、@loader_path（相对加载者）、@executable_path（相对主程序）三种占位符做可重定位路径解析，配合install_name_tool修改、otool -L查看依赖。
4.2 加载器与启动流程
- Windows ：内核建立进程后，由用户态
ntdll.dll中的加载器负责映射模块、解析导入表（IAT），并调用DllMain。 - Linux ：内核读取 ELF 程序头映射段，再跳转到
PT_INTERP指定的动态链接器（如ld-linux-x86-64.so.2），由其完成符号解析后跳转到程序入口。 - macOS ：内核把控制权交给动态链接器
dyld，dyld 解析 Load Commands、递归加载依赖、做绑定（binding）与重定位，再启动main。
三者都支持延迟绑定（lazy binding）和符号插桩，但在导入表 / 符号表的具体组织上各不相同。
五、安全与权限模型的差异
| 机制 | Windows | Linux | macOS |
|---|---|---|---|
| 能否运行 | 扩展名 + 数字签名 + SmartScreen | 文件执行权限位 （chmod +x）+ 魔术字 |
执行权限 + 强制代码签名 / 公证（Notarization） |
| 防篡改 | Authenticode 签名验证 | 内核模块签名、dm-verity | 签名 + Gatekeeper 公证，未签名会被拦截 |
| 细粒度限制 | UAC、AppLocker | SELinux / AppArmor、Capabilities | SIP（系统完整性保护）、沙箱 |
| 常见坑 | 杀软 / SmartScreen 误拦截、DLL 劫持 | 忘加执行权限、glibc 版本不兼容 | 未签名 / 未公证被系统阻止运行、架构不匹配 |
实践含义：在 macOS 上分发未签名、未公证的二进制，用户会直接遇到"无法打开 / 已损坏"提示；在 Linux 上忘记 chmod +x 会报 Permission denied；在 Windows 上则可能触发 SmartScreen 警告或杀软误报。跨平台发布时，签名、公证、执行权限是必须分别处理的三件事。
六、给开发者的跨平台实践建议
- 不要试图直接拷贝可执行文件跨系统运行：指令集与 ABI 都必须匹配，要么在目标平台分别编译，要么走兼容层（Linux 上的 Wine 转译 Windows PE，macOS 上 Rosetta 2 转译 x86-64 到 arm64）。
- 优先用统一工具链降低心智负担 ：LLVM / Clang + LLD 已能生成 PE、ELF、Mach-O 三种格式（通过
--target指定目标三元组），Rust、Go 也内置交叉编译能力（GOOS/GOARCH、Rust--target）。 - 发布时按平台分别打包并处理签名：Windows 走 Authenticode 签名；macOS 走 Developer ID 签名 + 公证；Linux 通常按发行版（deb / rpm / AppImage）分发。
- 善用架构维度：macOS 优先产出 Universal Binary；其余平台在 CI 中针对 x86-64 与 arm64 分别交叉编译，再统一打包。
- 用对应工具排查依赖 ：Windows 用
dumpbin /dependents，Linux 用ldd/readelf，macOS 用otool -L/vtool。
七、一句话总结
可执行文件的差异，本质是三套操作系统为"如何把字节变成进程"各自定义了一套容器格式与加载契约：Windows 用 PE、Linux 用 ELF、macOS 用 Mach-O。它们在文件魔术字、内存映射依据、动态库查找、多架构打包与代码签名上各有设计取舍。理解这些差异，才能真正搞懂"为什么这份代码在我电脑能跑、在服务器上跑不了"，也才能设计出健壮的跨平台构建与发布流程。