编译在栈中预留内存空间的机制及相关技术疑问

问题1：为何在一台计算机编译生成的可执行文件复制到另一台计算机仍能运行？ #

首先要明确：不是所有情况都能跑，得是相同CPU架构+相同操作系统（比如x86_64架构的Linux可执行文件，只能在同架构的Linux机器上运行）。
核心原因是：编译生成的可执行文件用的是虚拟地址，而非物理RAM的真实地址。操作系统加载可执行文件时，会把文件里的虚拟地址映射到当前机器的物理内存地址上——每个进程都有独立的虚拟地址空间，和其他进程、物理内存的实际布局不冲突。只要两台机器的架构和系统兼容，就能完成这个映射，让程序正常运行。

问题2：若编译时预留RAM的特定内存地址，可执行文件的数量（或编译次数）是否受RAM大小限制？ #

这是个误解：编译阶段根本不会预留物理RAM的特定地址。
编译时只是在可执行文件里定义了虚拟地址空间的布局规则（比如栈、堆的虚拟地址范围），但虚拟地址是操作系统给每个进程单独分配的“假地址”，和物理RAM没有直接绑定。
编译次数或者可执行文件的数量只受磁盘空间限制——只要你磁盘够，想编多少编多少。只有当你运行这些可执行文件时，系统才会给每个进程分配物理RAM，但那是运行阶段的事，和编译没关系。

问题3：若编译时在RAM中预留空间，为何可执行文件占用的磁盘空间远大于编译前的.C文本文件？ #

先纠正前提：编译时不会在RAM里预留空间，可执行文件变大的原因主要有这几点：

• 机器码体积更大：C源文件是ASCII文本，每个字符占1字节；编译后变成CPU能直接执行的二进制机器码，一条简单的C语句可能对应多条机器指令，每条指令占2~8字节不等，整体体积自然会膨胀。
• 包含额外数据与元数据：可执行文件里不仅有指令，还包含全局变量、字符串常量的二进制值，以及操作系统加载程序需要的段表、程序头等元数据；如果是静态编译，还会把依赖的库代码直接打包进去，体积会更大。
• 调试信息（可选）：如果编译时加了-g参数生成调试版本，可执行文件还会包含变量名、代码行号等调试信息，进一步增大体积。

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