C语言中未知待存储字符串长度时如何为char*正确分配内存

固定分配1024字节的写法被认为不规范，核心问题从来不是1024这个数值选得不对，而是这种写法天然带两个缺陷：一是输入远小于1024字节时会造成无意义的内存浪费，二是一旦输入长度超过1023字节（留1字节存字符串结束符\0），strcpy这类无边界检查的操作会直接冲掉缓冲区外的内存，触发未定义行为，严重点就是可被利用的内存漏洞。
你了解到的512、1024这类2的幂次块大小对处理器运算、内存分配器友好的结论是对的——主流malloc实现本身就对2的幂次大小的内存块有优化，同时对齐到缓存行大小的内存块也能减少CPU缓存miss，但这个优化点完全不需要靠硬编码固定大小的缓冲区来实现。

通用解决方案 #

根据你能不能对数据源做两次遍历，选对应的方案即可：

方案1：先统计长度再精确分配 #

如果你的数据源支持重复读取、或者本身就在内存里（比如命令行参数、内存中已有的字符串、支持回卷seek的本地文件），这是效率最高、内存利用率最好的方案：

• 先遍历一遍所有待拼接/拷贝的内容，统计出总字节数
• 按总长度 + 1的大小分配内存（多的1字节留给字符串结束符\0）
• 再把内容拷贝到新分配的缓冲区里
  你提到的示例场景里用strlen测av[0]长度再分配，就属于这类方案，没有任何多余的内存开销，也不会出现溢出问题。

方案2：动态扩容的弹性缓冲区 #

如果你没法提前遍历数据源拿总长度——比如从网络socket读数据、从标准输入逐行读内容、边生成边拼接字符串，就用渐进式扩容的方案，这也是绝大多数C标准库、开源项目处理未知长度字符串的通用实现：

• 先分配一块初始大小的缓冲区，初始值直接选2的幂次即可（比如64、128、256，根据你业务场景下的常见输入长度定，这一步就可以吃到2的幂次内存块的优化收益）
• 维护两个计数变量：一个记录当前缓冲区的总容量，一个记录已经写入的内容长度
• 每次写入新内容前，先判断剩余空间能不能装下新内容+结束符，如果不够就触发扩容：一般是把当前容量直接翻倍（依然保持2的幂次，不丢对齐优化收益），用realloc重新申请内存，记得做失败判空
• 所有内容写入完成后，如果追求极致的内存利用率，可以最后调用一次realloc把缓冲区收缩到实际需要的精确大小，释放多余的内存
  给个简化的实现参考，比如从标准输入读未知长度的行：

#include <stdio.h>
#include <stdlib.h>

#define INIT_BUF_SIZE 128 // 初始大小选2的幂次
char* read_line(FILE *fp) {
    size_t cap = INIT_BUF_SIZE;
    size_t len = 0;
    char *buf = malloc(cap);
    if (!buf) return NULL;

    int ch;
    while ((ch = fgetc(fp)) != EOF && ch != '\n') {
        // 预留当前字符+结束符的位置，不够就扩容
        if (len + 2 > cap) {
            cap *= 2;
            char *new_buf = realloc(buf, cap);
            if (!new_buf) {
                free(buf);
                return NULL;
            }
            buf = new_buf;
        }
        buf[len++] = ch;
    }
    buf[len] = '\0';

    // 可选步骤：收缩到实际需要的长度，不浪费空间
    char *res = realloc(buf, len + 1);
    return res ? res : buf;
}

固定大小预分配的适用场景 #

不是说固定分配1024字节的写法完全不能用，它只适合边界完全可控的场景：

• 你明确知道待处理的内容有强制的长度上限，比如POSIX系统下文件路径最大长度是PATH_MAX（通常为4096），这种场景按上限分配固定大小缓冲区完全合理
• 临时使用的短缓冲区，输入完全由程序自身生成，不存在外部可控的超长输入，处理完马上释放

只要输入可能来自用户、网络接口、第三方模块等不可信来源，绝对不要用固定大小缓冲区搭配strcpy、gets这类无边界检查的函数，这是C程序里内存溢出漏洞的最常见诱因。

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