跨DLL传递std::string或std::vector会崩溃，因不同模块使用不兼容的CRT堆分配器或STL ABI，导致析构时内存误释放；应改用extern "C"导出POD结构体或调用者提供缓冲区。
跨 DLL 传递 std::string 或 std::vector 为什么会崩溃
不是对象本身有问题，而是它们内部的堆分配器不一致。比如 DLL A 用自己的 CRT（如 msvcp140.dll）调用 new 分配了 std::string 的缓冲区，主程序 B 却用自己链接的 CRT（可能是静态链接的 libcmt.lib）在析构时调用 delete[] —— 两套堆管理器互不认识，直接触发堆损坏或静默内存破坏。
这种问题在 Windows 上尤其隐蔽：Debug 和 Release CRT 不兼容、/MD 和 /MT 混用、甚至不同 VS 版本生成的 DLL 都可能因 STL 实现细节差异而崩溃。Linux 上则是 libstdc++ 版本或 libc++ 混用导致 std::string::data() 返回的指针被错误释放。
- 不要跨模块传递任何含内部堆分配的 STL 类型（
std::string、std::vector、std::shared_ptr等） - 即使两个模块都用 /MD，也不能保证 STL ABI 完全兼容（尤其是 C++17 后 string 的 small-string 优化实现有差异）
- 调试时看到
HEAP CORRUPTION DETECTED或double free，优先怀疑这类跨模块析构
extern "C" + POD 结构体是跨模块最稳的传递方式
把数据“扁平化”成纯数据，彻底绕过构造/析构和堆分配逻辑。例如传递字符串，不用 std::string，改用固定长度数组或长度+指针组合：
struct Message {
const char* data;
size_t len;
};
关键点在于：所有字段必须是 POD（Plain Old Data），不能含虚函数、非平凡构造/析构、STL 成员。这样结构体可按字节拷贝，内存布局完全可控。
- DLL 导出函数返回
Message时，data必须指向 DLL 内部的静态缓冲区、常量字符串字面量，或由调用者提供缓冲区（见下一条） - 如果
data指向 DLL 堆分配内存，仍需配套导出一个free_message_data()函数，且调用者必须用它释放——不能用free()或delete - 避免使用
std::string_view：它虽是 POD，但生命周期依赖外部存储，跨模块传递时极易悬垂
调用者提供缓冲区（Caller-Allocated Buffer）模式
把内存分配责任明确交给调用方，DLL 只负责填充。这是最安全、最易排查的方案，适用于已知最大尺寸的场景（如日志消息、错误描述、JSON 序列化结果）。
典型接口设计：
// DLL 导出 int get_error_message(char* buffer, size_t buffer_size, int error_code);
- 返回值表示实际写入长度（不含终止符），若
buffer_size不足则返回所需最小尺寸（负值或正值依约定） - 调用者用栈或自有堆分配
buffer，确保生命周期覆盖使用全程 - DLL 内部绝不调用
malloc/new分配该 buffer 所指内存，只做strncpy类操作 - 比 “DLL 分配 + 调用者释放” 更可靠，因为避免了跨模块释放的 ABI 绑定
为什么不能依赖统一 CRT（如全用 /MD）来一劳永逸
理论上，所有模块链接同一个动态 CRT（如 msvcr140.dll）能解决堆管理器不一致问题。但现实中几乎不可行：
- 第三方库（如 OpenSSL、protobuf）往往自带静态 CRT，你无法控制其构建选项
- 插件架构中，不同团队开发的 DLL 可能用不同 VS 版本编译，
msvcp140.dll和msvcp142.dll不兼容 - Windows 系统级 DLL（如
comctl32.dll）可能间接加载另一套 CRT，污染进程全局堆 - 即便 CRT 统一，STL 容器的 ABI 仍受编译器版本、标准库实现、模板实例化方式影响，
std::vector在 VS2019 和 VS2022 中可能内存布局不同
真正稳定的做法，是让跨模块边界的数据交换停留在 C 层级：无状态、无构造析构、无隐式内存管理。一旦开始传递 C++ 对象，就等于把 ABI 兼容性赌注押在编译器和标准库的实现细节上——而这些细节，恰恰是 C++ 标准明确不保证的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
