跨dll传std::string会运行时崩溃，因不同模块abi不一致导致内存布局、析构符号、vtable偏移错配，引发访问越界、double-free等；根本解法是用c接口+手动内存管理。
为什么跨DLL传std::string会悄无声息崩溃
不是链接时报错，而是运行时访问越界、double-free 或虚函数跳转错位。根本原因是：不同模块可能用不同 ABI 编译（比如 _GLIBCXX_USE_CXX11_ABI=0 和 =1），导致 std::string 内存布局、析构符号、vtable 偏移全不一致。一个模块 new 的空间，另一个模块 delete 就崩。
常见现象包括：
- 中文显示乱码（实际是 SSO 缓冲区越界读）
- 调用
c_str()后立刻失效（底层堆内存被另一模块释放） -
LD_DEBUG=symbols显示加载了两个libstdc++.so.6版本 -
nm -D your.dll | grep _ZTSNSt7__cxx1112basic_string返回非空，说明用了 C++11 ABI 字符串
用 std::string_view 替代参数传值但必须守生命周期
std::string_view 本身不分配内存，只存指针+长度，传参开销极小。但它不管理数据生命周期——这是它最危险也最容易被忽略的点。
正确用法：
- 函数参数接收字面量、
std::string或 C 字符串，且函数内只读不修改 - 不能返回局部
std::string构造的string_view（悬空） - 避免在异步回调或缓存中长期持有
string_view，除非你 100% 控制原始字符串的存活期 - Windows 上注意：VC++ 2015+ 支持，但旧版 MSVC 可能无完整实现，需检查
__cplusplus >= 201703L
导出 C 风格接口 + 手动内存管理才是跨库安全底线
只要接口里出现 std::string、std::vector、引用或模板，就等于把 ABI、编译器版本、STL 实现细节全部暴露出去。跨 DLL/跨语言（C#、Python）基本不可靠。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
推荐做法：
- 导出纯 C 函数：
void parse_data(const char* data, size_t len) - 若需返回字符串，用输出参数：
int get_result(char* out_buf, size_t* out_len)，由调用方分配缓冲区 - 或用“分配-使用-释放”三段式：
char* allocate_result(); void free_result(char*)，且allocate_result和free_result必须来自同一模块（防止跨堆释放） - 所有 STL 类型仅限模块内部使用，绝不跨
.dll/.so边界
构建时强制统一 ABI 是预防性措施，但无法替代接口设计
即使你控制全部源码，也不能假设默认 ABI 一致。GCC 5+ 默认启用 C++11 ABI，但很多遗留项目仍设 _GLIBCXX_USE_CXX11_ABI=0；MSVC 不同版本对 std::string 的 SSO 阈值也不同（15 vs 22 字节）。
必须显式统一：
- 所有模块编译时加
-D_GLIBCXX_USE_CXX11_ABI=1（或全为 0） - 链接时确保只加载一个
libstdc++.so.6（用readelf -d your_executable | grep NEEDED检查） - 禁止混用
/MD和/MT（Windows）：必须全用动态 CRT（/MD），否则堆不共享 - Linux 下可用
objdump -t your.so | grep string查看符号是否含__cxx11后缀，不一致就直接排除
ABI 统一只是让崩溃变少，不是让 std::string 跨库变安全。真正可靠的边界永远是 C 接口 + 明确所有权语义。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
