Clang动态库无标准初始化函数，其.so或.dylib的初始化由运行时（如glibc、libSystem）处理，非Clang定义；用户可使用__attribute__((constructor))实现加载时执行，Windows则需显式实现DllMain；libclang通过clang_createIndex()惰性初始化，无需预调用初始化函数。
Clang动态库的初始化函数不是标准接口
Clang本身不提供类似__attribute__((constructor))或DLL_PROCESS_ATTACH那样的“动态库初始化函数”标准机制。你写的.so（Linux）或.dylib（macOS）里没有Clang专属的初始化入口——那是链接器和运行时（如libSystem、glibc）负责的事，Clang只管编译。
真正起作用的是底层C运行时约定，不是Clang定义的。如果你在代码里看到“Clang初始化函数”，大概率是混淆了编译器（Clang）和运行时行为（如libc++初始化、LLVM工具链组件加载）。
想让动态库加载时自动执行代码？用__attribute__((constructor))
这是GCC/Clang都支持的扩展，不是标准C，但在实际动态库开发中广泛使用。它会在共享库被dlopen()或随主程序加载时，优先于main()执行。
- 必须是全局函数，无参数、无返回值（
void） - 多个constructor按编译顺序或
__attribute__((constructor(101)))中的优先级数字排序（数字越小越早） - 不能依赖其他尚未初始化的全局对象（比如未初始化的
std::string静态变量），否则触发UB - macOS上需确保链接时未加
-no_compact_unwind等干扰运行时栈展开的选项，否则可能跳过constructor
示例：
__attribute__((constructor))
static void my_init() {
// 这里写初始化逻辑
// 注意：不要调用尚未dlopen的其他库符号
}
Windows下DLL怎么办？用DllMain，但Clang不特殊处理
Clang在Windows上生成DLL时，仍遵循MSVC兼容的PE格式规范。DllMain是Windows系统要求的入口，Clang只是把它当作普通函数编译进去，不插手逻辑。
- 签名必须严格为：
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) - 仅在
fdwReason == DLL_PROCESS_ATTACH时做初始化，且避免调用LoadLibrary、malloc、CRT函数（如printf）等可能引发重入的操作 - Clang默认不定义
DllMain——你得自己写；没写就用CRT提供的空桩，什么也不干 - 若用
-mno-cygwin或目标为x86_64-w64-windows-gnu，链接器（ld）会尝试合成，但行为不可靠，务必显式实现
LLVM/Clang相关库（如libclang）有自己的初始化约定
如果你实际想用的是libclang（Clang的C API封装库），它提供clang_createIndex()作为“初始化起点”，但这不是动态库加载钩子，而是API使用惯例：
-
clang_createIndex()内部会惰性初始化LLVM后端、词法分析器等资源 - 不需要提前调用某个“初始化函数”，更不依赖
constructor——直接调用即可 - 多个线程并发调用
clang_createIndex()是安全的（内部有原子控制） - 错误常见于：没链接
-lclang、路径不对导致dlopen失败、或误以为必须先调某个隐藏init函数
典型用法就是：
CXIndex idx = clang_createIndex(0, 0); // 这行就触发必要初始化
Clang动态库本身没有“初始化函数”这个概念，所有自动执行逻辑都来自操作系统运行时或用户主动调用的API。最容易出错的是把libclang的API调用时机和.so加载时机混为一谈，或者在constructor里做了跨库依赖或非异步信号安全操作。
