必须禁用跨DLL/.so边界传递STL容器——因编译器版本、运行时、STL实现等差异会导致内存损坏或崩溃；正确做法是仅使用C ABI接口，明确内存分配/释放责任，如传const char**+size_t并配套free函数。
不能安全传递。跨 DLL / .so 边界直接传 std::vector、std::string、std::map 等 STL 容器，不是“慎用”，而是“必须禁用”——只要模块间编译器版本、运行时（/MD vs /MDd）、STL 实现（MSVC STL / libstdc++ / libc++）或 even 同一 STL 的 minor 版本不一致，就会触发内存损坏、析构崩溃、读越界或静默数据错乱。
为什么 std::string 和 std::vector 在 DLL 间传参必崩
它们不是 POD 类型，内部依赖：std::allocator 实例、静态 type_info 布局、小对象优化（SOO）缓冲区大小、引用计数策略等实现细节。当 EXE 用 MSVC v143 构建，DLL 用 v142 构建时：
-
std::string的 SOO 阈值可能从 15 字节变成 22 字节，导致c_str()返回栈上地址被 EXE 当作堆指针释放 -
std::vector的_M_start成员偏移在两个模块中不一致，size()读出的值被截断或解释为负数 - EXE 调用 DLL 中构造的
std::string的析构函数时，实际调用的是 EXE 自己的operator delete，但内存由 DLL 的malloc分配 → heap corruption
正确做法：只暴露 C ABI 接口 + 显式内存责任划分
所有跨模块边界的数据交换，必须降级到 C 兼容层。核心原则是：接口中不出现任何 C++ 类型，所有内存分配/释放归属明确。
- 输入字符串数组：接收
const char* const*+size_t count，内部深拷贝进std::vector<:string></:string> - 输出字符串数组：返回
char**+size_t*，配套提供void free_string_array(char**, size_t)，且该函数必须由同一 DLL 实现并导出 - 容器内容序列化：若需传递结构化数据，用 flatbuffer / protobuf / 自定义二进制协议，把
std::vector<mystruct></mystruct>序列化为uint8_t*+size_t len，双方约定解析逻辑 - 禁止封装句柄（如
typedef void* VecHandle）却不暴露完整操作集——这等于把内存管理漏洞外包给调用方
std::any 和自定义 allocator 都不是解药
有人尝试用 std::any 包一层再传，或用共享内存 + 自定义 Allocator 让多个进程共用 std::vector，这两条路在多 DLL 场景下同样危险：
立即学习“C++免费学习笔记（深入）”；
-
std::any的内存布局（SOO 缓冲区大小、type_info 指针位置）在不同 STL 实现间无 ABI 保证；GCC 12 生成的std::any{42}无法被 Clang 16 的 libc++ 正确识别 - 共享内存中的
std::vector<t sharedalloc></t>要求所有使用方链接同一份 allocator 实现，并确保SharedAlloc::allocate()返回的地址对所有进程映射到相同虚拟地址——现实中几乎不可控 - 即使 allocator 可靠，
std::vector内部仍含虚表指针、调试标记等非 POD 成员，在跨模块加载时可能被重定位错误
真正容易被忽略的一点：不是“怎么让 STL 过去”，而是“谁来负责生命周期”。只要接口契约里没写明“调用方 malloc，DLL free”或“DLL malloc，调用方 free_string_array”，就已埋下崩溃伏笔。ABI 稳定性不靠技巧兜底，靠契约显式声明。
