不能跨DLL/.so边界传递std::string等STL容器，因ABI不兼容必致崩溃；应仅用C兼容接口，如const char*+size_t或裸指针+长度，所有STL对象须在模块内构造与销毁。
不能直接跨 DLL / .so 边界传递 std::string 或任何 STL 容器（如 std::vector、std::map）的值、引用或指针。 这不是编码风格问题，而是 ABI 不兼容导致的必现崩溃——尤其在 Windows MSVC 与 MinGW、Linux GCC 与 Clang、或不同 STL 版本混用时。
为什么 std::string 跨动态库传参会崩溃？
STL 实现（libstdc++、libc++、MSVC STL）对 std::string 的内存布局、小字符串优化（SSO）阈值、size_type 定义、甚至析构行为都可能不同。模块 A 编译时把 std::string 当作 24 字节对象构造并写入，模块 B 加载时按 32 字节解析，data() 指针错位、size() 读出垃圾值，后续 operator[] 或 c_str() 直接触发访问违规。
- 即使同一编译器，不同标准库版本（如 GCC 11 vs GCC 13 的 libstdc++）也可能变更 SSO 阈值，导致
std::string在“堆分配”和“栈内存储”之间行为不一致 -
std::string的拷贝构造/赋值运算符不是 trivial，跨模块调用时若 ABI 不匹配，析构函数可能没被正确调用，造成内存泄漏或 double-free - Windows 上更危险：MSVC STL 默认启用“动态链接 STL”，但若模块 A 静态链接、模块 B 动态链接，
std::string的分配器（std::allocator<char></char>）会分别从不同堆申请内存，delete时必然崩溃
安全替代方案：只传 C 兼容接口
核心原则：跨模块边界只使用 POD 类型、裸指针 + 长度、C 风格函数签名。所有 STL 对象必须在模块内部完成构造与销毁。
- 传字符串：用
const char*+size_t（显式长度，避免依赖\0），接收方用该数据构造本地std::string；不要返回std::string，改用输出参数char* buf+size_t* out_len，由调用方分配缓冲区 - 传容器内容：不传
std::vector<int></int>，改传const int*+size_t count；若需返回数组，提供两阶段 API：size_t get_result_count()和void get_result_data(int* out_buf, size_t max_count) - 禁止传引用或指针：
const std::string&、std::vector<t>*</t>同样不可靠——引用绑定到模块 A 的对象，模块 B 无法保证其生命周期；裸指针更危险，连所有权语义都没有 - 若必须封装结构体，确保是纯 C 风格：
struct Config { int version; char name[64]; float values[16]; };，不含任何 STL 成员、虚函数、非 trivial 构造/析构
如果非要共享容器逻辑，用静态链接 + 统一 STL
仅限于你完全控制所有模块构建环境的场景（如嵌入式固件、单供应商 SDK）。否则请跳过此条。
立即学习“C++免费学习笔记（深入）”；
- 所有模块强制使用同一套 STL：例如全部用 libc++ 并静态链接（
-stdlib=libc++ -static-libc++），或全部用 MSVC STL 并设为 /MD（动态链接）且版本严格一致 - 所有模块统一编译器与标准：C++17、相同优化等级（-O2）、相同调试宏（_GLIBCXX_DEBUG 等必须全关）
- 禁用 SSO 可变性：通过宏定义固定 SSO 缓冲大小（如 libstdc++ 的
_GLIBCXX_USE_CXX11_ABI=1+ 自定义_GLIBCXX_STRING_CAPACITY），但这属于 hack，不推荐用于交付版本 - 即便如此，仍禁止跨模块传递
std::shared_ptr<:vector>></:vector>—— 智能指针的控制块内存分配器来源必须一致，而跨 DLL 的new/delete很可能来自不同堆
真正棘手的地方不在“怎么传”，而在“谁负责释放”和“ABI 是否真一致”。哪怕两个模块都用 GCC 12，一个用了 -D_GLIBCXX_DEBUG，另一个没用，std::vector 的大小就差 8 字节。别赌 ABI 兼容性，用 C 接口兜底最稳。
