最可靠的main前执行方式是全局对象构造和编译器__attribute__((constructor))扩展；前者标准可移植，后者高效但需平台适配，其余方法或时机不准或代价过高。
全局对象的构造函数会在main之前执行
这是最常用、最标准的方式：定义一个全局（或静态）对象，它的构造函数就会在 main() 进入前被自动调用。C++ 标准保证所有非局部变量的动态初始化在 main() 开始前完成（前提是不涉及跨编译单元的初始化顺序问题）。
常见错误现象：std::cout << "init\n"; 在全局作用域直接写，会报错 —— C++ 不允许在命名空间作用域执行表达式语句，只能声明。
- 正确做法是封装成类，靠构造函数“触发”逻辑
- 如果初始化逻辑简单，也可以用
inline constexpr变量 + 函数调用，但真正执行仍需靠副作用，所以还是得靠构造函数或std::call_once配合静态局部变量 - 注意：多个全局对象分布在不同 .cpp 文件时，它们的初始化顺序是未定义的（仅同个编译单元内按声明顺序）
使用__attribute__((constructor))（GCC/Clang）
这是编译器扩展，不是标准 C++，但在 Linux/macOS 下很实用。给一个无参、无返回值的函数加上这个属性，链接器会把它注册为程序启动时的“构造器”，在 main() 之前执行。
使用场景：需要快速插入一段初始化逻辑，又不想引入类或全局对象；或者要确保在 C 运行时（如 libc 初始化之后、但 main() 之前）运行。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 函数必须是
static或匿名命名空间内，否则可能引发 ODR 违规 - 不能带参数，不能有返回值，签名必须是
void func(void) - 多个
constructor函数之间执行顺序可用优先级控制，例如__attribute__((constructor(101)))，数值越小越早执行 - MSVC 不支持该属性，换用
#pragma init_seg或 DLL 的DllMain（仅 Windows 动态库）
static void early_init() {
std::cout << "before main (GCC)\n";
}
__attribute__((constructor)) static void run_early_init() {
early_init();
}静态局部变量的首次访问（延迟但确定的初始化）
这不是严格意义上的“main 前”，而是“首次调用时才初始化”，但它常被误认为是替代方案。实际上它发生在第一次执行到该变量声明处时，属于运行期懒初始化，和 main 前无关 —— 除非你在某个全局对象构造函数里调用了它。
容易踩的坑：有人以为在全局作用域写 static auto _ = []{ /* init */ }(); 就能提前运行，其实这是合法的（C++11 起允许 lambda 立即调用并丢弃），但它本质仍是全局对象构造（生成了一个匿名函数对象并立即调用其 operator()），和显式定义类没区别，只是语法糖。
- 真正延迟初始化的典型是
static std::once_flag flag; std::call_once(flag, []{ ... });，它只在第一次调用时执行一次，但时机完全由你控制 - 别依赖静态局部变量“自动在 main 前跑”，它不会 —— 除非你主动在某个更早触发的上下文中访问它
main 入口替换（不推荐，但可行）
通过链接器选项（如 GCC 的 -e）指定自定义入口点，绕过默认的 __libc_start_main 流程，自己实现启动逻辑，最后再手动调用 main()。这属于底层系统编程范畴。
性能 / 兼容性影响极大：你将失去 libc 对 argc/argv 解析、环境变量设置、信号处理初始化、atexit 注册等全部保障。
- 仅适用于嵌入式、bootloader、极简容器或教学演示
- 必须用汇编或
extern "C"C 风格函数，且签名要匹配平台 ABI（如 x86_64 Linux 是void _start()） - 一旦出错，程序很可能直接 segfault，连堆栈都打不出来
真正可靠的 main 前执行，只有两类路径：全局对象构造（标准、可移植）、编译器 constructor 属性（高效、需平台适配）。其余方式要么时机不对，要么代价过高。跨文件初始化顺序、异常是否允许抛出、以及静态析构的逆序问题，才是实际项目中最容易被忽略的复杂点。
