核心前提 #

标准C语言规定：由malloc（及strdup、asprintf等基于malloc的函数）分配的内存，必须用free释放，但这有个隐藏前提——两者必须属于同一个堆上下文。现实中因为编译环境、链接方式的差异，这个前提不一定总能满足，这就是你当年VS6遇到问题的根源。

调用free安全的场景 #

• 同上下文分配释放：你自己的代码里，用当前编译单元的malloc分配的指针，直接用同上下文的free释放，绝对安全。比如单个.c文件里写的char* buf = malloc(100); free(buf);，不会有任何问题。
• 第三方明确约定：如果某个库的文档明确说明“返回的指针由标准malloc分配，可直接用free释放”，且你使用的运行时和库匹配（比如同是动态链接CRT），也可以放心调用free。

调用free不安全的场景 #

• 跨模块/跨CRT边界：这是最常见的坑。比如一个用静态链接CRT编译的DLL，返回一个malloc分配的指针，主程序用动态链接CRT的free去释放——两个CRT维护的是完全独立的堆，free根本找不到对应的内存块信息，直接崩溃。你当年VS6遇到的“静态/动态链接、调试/发布、单/多线程”矩阵问题，本质就是这个：不同配置的CRT对应不同的堆。
• 调试/发布版本不匹配：调试版CRT会在分配的内存前后加校验信息，发布版CRT没有这些信息。如果用调试版malloc分配，发布版free释放，会因为内存结构不匹配导致错误。
• 指针非法：比如指针已经被free过（重复释放）、指针被篡改过（比如buf += 10后再free），这种情况不管什么上下文，都会出问题，但这属于代码错误，不是兼容性问题。

编写返回malloc指针的函数：要不要配套释放函数？ #

分两种情况处理：

• 单模块/明确依赖标准运行时：如果你的函数只在当前项目内使用，或者你明确要求调用方用和你一致的CRT编译，直接在文档里写“返回指针由malloc分配，请用free释放”就行，这是C开发的常规做法，没必要多写一个配套函数。
• 跨模块/库开发：如果你的函数会被其他模块（比如DLL、静态库的外部调用者）使用，必须提供配套的释放函数，比如my_allocated_data_free(void* ptr)。因为你没法控制调用方的编译配置，配套函数内部用你自己的free去释放，能彻底避免跨堆问题。

实践中malloc与free不兼容的概率 #

• 单模块程序：几乎为0，只要你不犯指针操作的低级错误，同上下文的malloc和free完全兼容。
• 跨模块/跨CRT场景：概率极高，尤其是Windows平台，不同编译配置的CRT堆是完全隔离的，直接跨模块free大概率崩溃。Linux/macOS下相对友好，系统默认用全局堆，但如果是静态链接libc的库，依然会出现不兼容的情况。

内容的提问来源于stack exchange，提问作者Maciek