静态库（.a）在编译时将代码完全嵌入可执行文件，体积大、运行独立；动态库（.so）仅在运行时加载，体积小、需外部依赖，支持共享内存与热更新。
编译器对不同构建目标（如调试版、发布版、静态库、动态库、跨平台目标等）的处理方式差异显著，这些差异直接影响生成代码的行为、性能、体积和可移植性。
优化级别与目标类型强相关
构建目标直接决定编译器启用哪些优化策略。调试目标（如 -O0 -g）禁用大部分优化，保留完整符号和行号信息，便于断点调试；而发布目标（如 -O2 -DNDEBUG）会内联函数、消除死代码、展开循环，并可能重排指令顺序。Clang 和 GCC 在 -O3 下还会启用向量化，但 MSVC 默认需显式开启 /Qvec- 或使用 /O2 配合 /arch:AVX2 才生效。
- GCC/Clang：通过 -fvisibility=hidden 控制符号可见性，对动态库体积影响明显
- MSVC：用 /GL（全程序优化）配合链接时 /LTCG 实现跨编译单元优化，但仅适用于 EXE/DLL 构建，不支持静态库
- 所有主流编译器在构建静态库（.a/.lib）时都不做目标代码优化，只归档已编译的目标文件；优化发生在最终链接阶段
运行时依赖与目标格式绑定
构建目标决定了运行时行为的底层支撑。例如：
- Windows DLL 使用 MSVCRT 或 UCRT，GCC（MinGW-w64）默认链接 msvcrt.dll 或 ucrtbase.dll，二者 ABI 不兼容
- Linux shared object（.so）依赖 libc 版本，而 musl 编译的目标无法在 glibc 系统上直接运行
- 静态链接（-static）在 GCC/Clang 中可打包 libc，但 MSVC 不支持完全静态链接 CRT（除非用 /MT，仍需 Windows 系统 DLL 如 kernel32.dll）
目标平台架构触发不同后端行为
即使源码相同，指定不同目标架构（x86、x86_64、aarch64、riscv64）会让编译器切换代码生成后端，带来实质性差异：
- 寄存器分配策略不同：ARM64 有 31 个通用寄存器，x86-64 仅 16 个，影响函数调用约定和溢出频率
- 指令选择差异：GCC 对 aarch64 默认启用 -mgeneral-regs-only 约束，而 x86-64 可自由混合整数与浮点寄存器
- 栈对齐要求不同：x86-64 要求 16 字节对齐，aarch64 要求 16 字节但部分 ABI 允许 128 字节对齐以适配 NEON
- Clang 的 --target=armv7-linux-gnueabihf 会自动插入 VFP 指令，而未指定时默认为通用 ARM 指令集
构建产物类型影响符号与链接逻辑
静态库、动态库、可执行文件三者在编译器处理阶段就有分叉：
- 静态库（.a/.lib）：编译器只生成 relocatable object（.o/.obj），不解析外部符号，也不做重定位
- 动态库（.so/.dll）：需标记导出符号（GCC 用 __attribute__((visibility("default")))，MSVC 用 __declspec(dllexport)），且地址无关（-fPIC / /MD）是强制要求
- 可执行文件：链接器负责符号解析和重定位，但编译器在生成目标文件时已根据 -pie 或 /DYNAMICBASE 决定是否生成位置无关代码
