递归结构体realloc失败：wisdom设为2时内存分配报错

这是个很典型的递归内存管理问题，结合你的代码来看，主要有两个最核心的可能原因，咱们一步步拆解：

1. 未初始化的followup指针导致堆损坏 #

这是最可能触发问题的点。看你的struct ai_move定义：

struct ai_move { 
    int pngn; 
    int coords[2]; 
    float aggro; 
    float safety; 
    int order; 
    struct ai_move* followup; // 未初始化的指针
    int followup_size; 
};

当你通过realloc创建新的ai_move实例时，followup成员会保留内存里的垃圾值（不是NULL）。

当wisdom=2时，递归进入order=1的层级，此时你调用assess_moves传入的是&((*ai_arr)[count-1].followup)——也就是这个未初始化的垃圾指针的地址。在递归的assess_moves里，执行：

temp = (struct ai_move*)realloc(*ai_arr, count * sizeof(struct ai_move));

这里的*ai_arr是那个垃圾指针，而不是合法的堆内存地址。realloc要求第一个参数要么是NULL，要么是之前malloc/realloc返回的有效地址，传入野指针会直接破坏堆结构，后续的内存分配操作就会失败，返回NULL。

而wisdom=1时，递归调用assess_moves后，order+1=1等于wisdom=1，直接返回0，不会进入循环执行realloc，所以这个问题被隐藏了。

修复方案： #

在创建新的ai_move时，显式初始化followup为NULL：

// 在设置完其他成员后添加这行
(*ai_arr)[count-1].followup = NULL;

这样递归调用时，realloc(NULL, size)就等价于malloc(size)，是完全合法的内存分配操作。

2. 递归层级提升导致内存需求激增 #

当wisdom从1提升到2时，AI会计算当前移动的后续所有可能移动，内存需求会呈指数级增长：

• wisdom=1：只计算当前层（order=0）的所有移动，不需要分配后续移动的内存
• wisdom=2：每个order=0的移动，都会递归生成order=1的所有可能移动，总内存占用会突然翻倍甚至更多

如果你的游戏地图较大，可能直接耗尽了进程可用的堆内存，导致realloc无法分配足够空间，返回NULL。

优化方案： #

• 剪枝优化：不需要保留所有后续移动，只筛选出aggro/safety评分较高的N个移动，减少内存占用
• 限制最大递归深度：如果wisdom需要更大的值，可以设置每个移动的后续移动数量上限
• 使用内存池：预先分配一块内存用于存储所有ai_move实例，避免频繁realloc的开销和碎片

调试建议 #

可以用内存检测工具（比如Valgrind）来验证堆损坏问题，它会直接指出野指针的使用位置，帮你快速定位问题。

内容的提问来源于stack exchange，提问作者Jack Jax Caster