c++oding="utf-8" ?>
llvm libc++要求可执行程序与插件严格使用同一版本、同一构建的动态或静态库，且编译器abi配置（-stdlib=libc++、-fno-rtti等）必须完全一致，否则运行时调用std::string等类型会因内存布局错位而崩溃。
LLVM libc++项目中，可执行程序与插件必须使用**完全相同的 libc++ 运行时二进制 + 相同的编译器 ABI 配置**，否则极大概率在首次调用 std::string 或 std::vector 成员函数时崩溃——这不是链接错误，而是运行时内存布局错位或虚表跳转失败。
libc++ 版本和构建方式必须严格对齐
libc++ 本身不提供 ABI 向后兼容保证；不同 LLVM 主版本（如 18.x vs 22.x）的 libc++.so / libc++.dylib / libc++.dll 是互不兼容的。即使只差一个小版本（如 22.1.7 → 22.1.8），只要其 libc++abi 子模块有变更（例如 Emscripten 当前就基于 llvm-project 的 emscripten-libs-22 分支），就可能破坏 std::exception 控制块或 __cxa_guard 的 ABI。
- 可执行程序与所有插件必须链接到**同一个 libc++ 动态库文件路径**（不能一个用系统自带，一个用自建）
- 若静态链接 libc++（
-static-libc++），则所有模块（主程序 + 插件）必须使用**完全相同的 libc++ 静态库（.a/.lib）文件**，且该 .a 必须由同一构建上下文生成（CMake 构建目录、编译器命令行参数全一致） - 禁止混合使用 libc++ 和 libstdc++：插件用 libc++、主程序用 GCC 的 libstdc++ 是典型崩溃组合，
std::string析构会 free 错误的内存池
编译器与标准库 ABI 配置必须显式锁定
Clang 编译 libc++ 项目时，ABI 行为受多个隐式开关控制，仅靠 -std=c++23 不足以保证一致性。关键配置项包括：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
-stdlib=libc++：必须显式指定，不可依赖默认值 -
-fno-rtti/-fno-exceptions：主程序与插件必须完全一致；若任一模块禁用 RTTI，则dynamic_cast或typeid在跨模块调用时直接 UB -
-fvisibility=hidden：推荐全局启用，避免插件导出符号污染主程序符号空间，引发std::allocator多次初始化等问题 - 无
-D_LIBCPP_ABI_UNSTABLE或类似宏：这些宏会开启实验性 ABI，严禁在生产插件系统中使用
插件接口必须规避 libc++ 类型暴露
只要插件头文件里出现 std::string、std::vector、std::shared_ptr 等类型作为函数参数或返回值，ABI 就已实质上泄露——因为这些类型的大小、构造/析构逻辑、分配器绑定都随 libc++ 版本浮动。
- 正确做法：插件导出纯 C 接口（
extern "C"），所有数据传递走const char*、void*、int32_t等 POD 类型 - 若必须用 C++ 接口，采用 Pimpl 模式，并确保 Impl 结构体中**不包含任何 libc++ 类型**（连
std::size_t都要慎用，改用uint64_t） - 禁止在插件头中
#include <string></string>或<vector></vector>；头文件应只含前向声明 + C 兼容结构体定义
运行时加载阶段需校验 libc++ ABI 元数据
即便编译期一切吻合，动态加载插件时仍可能因 libc++ 被多份加载（如主程序带一份、插件又 embed 一份）导致符号冲突或静态变量重复初始化。建议在 dlopen() 后立即检查：
- 读取插件 ELF/Mach-O 的
DT_NEEDED（Linux/macOS）或导入表（Windows），确认其依赖的libc++.so/libc++.dylib/libc++.dll与主程序所用为同一文件（用readelf -d/otool -L/dumpbin /dependents） - 在插件初始化函数中调用
std::string("test").data()并捕获 segfault —— 这是轻量级 ABI 健康检查，比等用户触发崩溃更早暴露问题 - 若使用 C++27 模块，必须确保主程序与插件共用同一份
.pcm缓存，且模块构建时启用set(CMAKE_CXX_EXTENSIONS OFF)，否则模块摘要索引中的 ABI 标记（如__abi_v2后缀）可能不一致
最易被忽略的一点：Emscripten 等交叉工具链自带的 libc++ 是定制分支（如 emscripten-libs-22），它和上游 LLVM 官方发布的 libc++ 二进制不兼容。这意味着 WebAssembly 插件和原生主机程序根本不可能共享 ABI——这种跨目标平台场景，必须彻底放弃动态插件思路，改用进程间通信或 WASI 接口契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
