_alloca（或alloca）是在栈上动态分配内存的非标准函数，函数返回时自动释放，不可用free/delete释放，不具可移植性，易致栈溢出，C99变长数组及std::vector等为其更安全替代。
alloca 分配的数组不能用 delete 或 free 释放
alloca 不是标准 C++ 函数，而是来自 <cstdlib>（C）或编译器扩展（如 GCC、MSVC），它直接在当前函数栈帧里分配内存，函数返回时自动回收。这意味着你**绝对不能**对 alloca 返回的指针调用 delete、delete[] 或 free——这些操作会触发未定义行为，常见表现为崩溃或静默内存破坏。
常见错误现象：free(): invalid pointer、double free、栈溢出后程序立即终止。
- 只在函数内部使用，且生命周期严格限定在该函数作用域内
- 不要把
alloca指针保存到全局变量、类成员或传给其他函数长期持有（除非你能 100% 确保接收方只在本栈帧内访问） - MSVC 下需包含
<malloc.h>；GCC/Clang 通常只需<cstdlib>或直接可用（依赖内置）
alloca 分配大小必须在编译期可评估？不，但必须是运行时确定的常量表达式
alloca 的参数是 size_t，可以是运行时变量，比如 int n = read_input(); char* buf = (char*)alloca(n); 是合法的——但它**不是**“动态”在堆上那种灵活生命周期的动态，而是在栈上“即时划一块地”，大小仍受栈空间限制。
容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
- 传入过大值（如几 MB）极易导致栈溢出，尤其在嵌入式、递归函数或默认栈小的环境（Windows 默认 1MB）
- 不能用于模板推导或
std::array构造：没有类型安全，不支持构造函数调用（即对非 POD 类型，alloca分配的内存里对象未被构造） - 调试困难：GDB 可能无法显示
alloca分配的变量名，只能靠地址和偏移观察
替代方案：为什么 std::vector 或 std::unique_ptr 更安全
绝大多数场景下，std::vector<T>（栈上小缓冲优化 + 堆后备）或 std::unique_ptr<T[]> 能覆盖 alloca 的用途，且自带异常安全、析构保证和类型支持。
例如：
// 用 alloca（危险，无构造） char* raw = (char*)alloca(n); // 用 vector（安全，自动管理，支持 T 的构造） std::vector<char> buf(n); <p>// 若只需栈上小数组且大小已知，用 std::array 更优 std::array<int, 256> stack_buf;
-
std::vector在小尺寸时可能触发 SSO（small string optimization 类似机制，取决于实现），实际并不一定分配堆内存 -
std::unique_ptr<T[]>配合new T[n]明确语义，且能抛异常，便于错误处理 -
alloca无法与 RAII 协作，一旦中间 throw 异常，栈帧未退出，但后续代码跳过，alloca内存虽仍存在，逻辑已失控
真需要 alloca 时，如何检查栈空间是否足够
没有可移植方式精确查询剩余栈空间，但可做粗略防护：
- 设定硬上限（如
if (n > 64 * 1024) throw std::runtime_error("alloca too large");） - GCC 提供
__builtin_frame_address(0)获取当前栈帧地址，配合线程栈边界（如pthread_attr_getstack）估算，但高度平台相关，不推荐用于生产 - 更务实的做法：仅在性能敏感、已知 size 很小（
真正难处理的是递归调用中层层 alloca ——每次调用都吃栈，叠加后极易爆栈，且难以复现。
