1. 一次动态库边界上的崩溃先看一个很容易写出来的接口。某个日志 SDK 提供Logger头文件里把类和工厂函数都暴露给调用方代码语言cppAI代码解释// logger_sdk.h调用方也能看到 Logger 的定义 class Logger { public: void Log(const char* msg); ~Logger(); private: std::vectorstd::string entries_; }; Logger* CreateLogger();实现放在logger.dll里代码语言cppAI代码解释// logger.dll 内部 Logger* CreateLogger() { return new Logger(); // 在 logger.dll 内部分配 }调用方拿到Logger*后自然会把它当普通 C 对象用代码语言cppAI代码解释// app.exe Logger* logger CreateLogger(); logger-Log(hello); delete logger; // 看起来合理问题就在这里这段代码的问题不在Log而在最后一行。Logger是在logger.dll内部分配的却在app.exe里释放。它看起来只是一个普通指针背后却跨过了动态库边界。这种崩溃很容易误导排查方向。堆栈可能停在free、delete或堆检查函数里表面上和业务对象没有关系Debug 和 Release 的表现还可能不一样。真正的问题是分配和释放落到了不同的内存管理器上。2. new 和 delete 背后的分配器堆栈停在free里看起来和delete logger对不上。中间缺的一环是new/delete背后的分配器。new Logger()不是只做一件事。它会先调用底层申请函数operator new拿到一块内存再在这块内存上执行构造函数。delete logger也分两步先执行析构函数再通过底层释放函数operator delete把内存还回去。这两个底层函数的默认实现通常不会自己管理整套堆结构而是继续调用运行时库里的分配器。运行时库可以先理解成 C/C 程序运行时依赖的一组基础能力内存分配也在里面。Windows / MSVC 里这层运行时常叫 CRTC Runtime。读者不需要记住缩写只要记住一点不同模块可能链接到不同的运行时副本也就可能有不同的堆。Linux 上也有类似的基础运行时只是常见场景下更容易共享同一套分配器。问题出在动态库边界上。每个模块都可能有自己的运行时链接方式也可能带自己的分配器。对象在哪个运行时或分配器里申请通常就应该回到同一个运行时或分配器里释放。跨模块释放把这个配对关系打断了。可以把不同模块想成两个 Worker。主线程可以让 Worker 创建对象也可以拿到一个句柄但不能直接伸手回收 Worker 内部的对象。更稳的方式是发消息让 Worker 自己清理。3. 运行时副本怎么造成跨堆释放在 Windows / MSVC 下同一个项目可以选择不同的运行时链接方式。/MD和/MT就是 MSVC 的运行时链接选项它们会影响模块背后的堆。/MD动态链接运行时库。多个模块通常共享同一份运行时内存分配器更容易保持一致。/MT静态链接运行时库。每个模块都带一份运行时副本可能形成各自独立的堆。如果logger.dll和app.exe都用/MT编译两边可能各有自己的运行时副本和自己的堆。logger.dll里的new在 heap A 上分配app.exe里的delete却拿着这个地址去 heap B 上释放。heap B 的分配器不认识这个地址堆内部的管理数据就可能被破坏。动态库边界上的堆错配这类问题的表现很随机有时立刻崩有时过了很多次分配才崩有时只在某个构建配置里复现。它破坏的是堆元数据真正爆炸的位置经常离错误代码很远。4. 二进制接口不一致也会出问题/MD能降低分配器不一致的风险但它不是跨模块delete的通行证。动态库边界上还有另一类问题两个模块都用 C 写不代表它们编译后的对象布局完全一样。比如字符串、动态数组这类标准库对象内部字段可能受编译器版本、标准库版本、Debug/Release 配置影响。调用方看到的对象布局一旦和 SDK 内部不一样访问成员、执行析构都可能出问题。std::string、std::vector就属于这一类。这类二进制层面的约定通常叫 ABIApplication Binary Interface应用二进制接口。它关注编译后的对象在内存里怎么摆、函数参数怎么传而不是源码表面长什么样。这里不需要展开 ABI 的所有细节只要记住跨动态库传 C 对象时两边必须按同一套规则理解这块内存。工程上不应该把这类一致性当成接口契约。动态库边界更适合收窄成 C 风格接口基本类型、指针、buffer、长度、句柄。复杂对象留在库内部创建和销毁也留在库内部。在 C 里导出这类 C 风格函数时常会看到extern C。它可以先理解成一个导出约定让函数名按 C 的规则暴露出去方便动态库查找。它只解决函数名怎么被找到不解决内存该由谁释放。5. 谁创建谁销毁调用方拿到一个Logger*后真正麻烦的是释放责任不清楚。这个指针背后的内存来自哪个模块、用的是new还是malloc、析构函数依赖哪个标准库调用方都不应该猜。接口应该把释放责任写清楚谁创建谁销毁。每个create配一个destroy并且这两个函数都在同一个模块里实现。分配释放流程对比代码语言cppAI代码解释Logger* logger_create(void) { return new Logger(); // 在库内部 new } void logger_destroy(Logger* p) { delete p; // 在库内部 delete }调用方只负责拿指针和归还指针代码语言cppAI代码解释Logger* logger logger_create(); logger-Log(hello); logger_destroy(logger); // 交给库自己释放这样new和delete永远在同一个模块内。调用方不需要知道内部对象是什么也不需要知道它来自哪个堆。字符串也遵守同一条规则。危险写法是让库返回一块新分配的内存代码语言cppAI代码解释// 危险DLL 里 new 的 char[]调用方不知道怎么释放 extern C char* GetVersion() { char* p new char[16]; std::strcpy(p, 1.0.0); return p; }调用方拿到char*后会遇到同一个问题该delete[]、free还是不释放接口可以给出两种更稳的选择。第一种是调用方传 buffer库只负责填充代码语言cppAI代码解释void logger_last_entry(Logger* logger, char* buf, size_t size); char buf[64]; logger_last_entry(logger, buf, sizeof(buf));第二种是库提供配套释放函数代码语言cppAI代码解释extern C char* GetVersion(); extern C void FreeString(char* p); // 在 DLL 内 delete[]配对能传 buffer 就优先传 buffer。它从根上避免了跨边界传递所有权调用方也不用猜该怎么释放。6. 只暴露一个看不见内部的句柄create/destroy配对解决了责任归属但它仍然依赖调用方自觉。如果头文件暴露了完整的 C 类定义调用方还是可能顺手写出delete logger。更稳的做法是只给调用方一个指针但不让它看到这个指针背后的结构体长什么样。这种写法通常叫不透明句柄。公开头文件里只前向声明结构体也就是只告诉编译器“有这么个类型”不暴露它的字段和大小代码语言cppAI代码解释typedef struct LoggerHandle LoggerHandle; LoggerHandle* logger_create(void); void logger_log(LoggerHandle* h, const char* msg); void logger_last_entry(LoggerHandle* h, char* buf, size_t size); void logger_destroy(LoggerHandle* h);真实头文件里通常还会用extern C包起来保证这些函数按 C 风格导出这里先省掉外层宏只看句柄设计本身。