返回局部数组地址会得到悬空指针，因函数返回后栈帧弹出，数组内存立即失效，后续访问将读取被覆盖的垃圾数据。
返回局部数组地址会拿到悬空指针
函数一返回，栈帧就弹出，局部数组所在的内存立即失效。此时返回的指针仍指向原栈地址，但那块内存已“无主”，后续任何函数调用、printf、甚至变量声明都可能覆盖它。你拿到的不是数据，是随时会变的垃圾。
常见错误现象：
-
printf("%s", get_name())有时能打印出正确字符串，有时乱码，有时直接段错误 - 在
gcc -O2下代码突然不工作，而-O0下看似正常——优化改变了栈布局和寄存器复用方式 - 多线程环境下，另一个线程的函数调用瞬间就把这块栈内存改写了
汇编层面看：ret 指令后 esp/rsp 已跳走，eax/rax 却还存着旧地址
以 x64 为例：retArray() 中定义 char buf[32]，编译器把它分配在 rsp - 32 开始的位置。函数末尾 ret 执行前，rax 被设为 rsp - 32（即数组首地址）；ret 一执行，rsp 就恢复成调用前值，buf 所在区域立刻退出保护范围。
关键点：
-
rax返回的是地址，不是数据拷贝——它不会把 32 字节内容搬出来 - 栈顶指针
rsp回退后，CPU 完全不关心那片内存里原来是什么 - 下一次
call或局部变量声明，push或sub rsp, 8就可能直接覆写那块区域
为什么 static 数组能返回，而局部数组不能
根本区别不在“是不是数组”，而在“内存落在哪”。static int arr[5] 的存储位置是数据段（.data），生命周期从程序加载起贯穿到结束；而 int arr[5] 在栈上，只活到 } 大括号结束。
注意陷阱：
-
static方案线程不安全：所有调用共享同一块内存，连续两次调用getNumbers()可能互相覆盖 -
static不可重入：递归调用或信号处理中使用会出问题 - 即便加了
const（如static const char msg[] = "ok"），地址依然有效，但内容不可改——这反而是最安全的只读场景
真正安全的返回方式只有三种
别被“返回数组”这个说法带偏——C++ 里没有“返回数组类型”的语法，所有所谓“返回数组”，本质都是返回指针或引用。安全与否，只取决于指针指向的内存是否在调用方使用时仍然有效。
- 用
std::vector或std::array：它们内部管理堆内存或栈内存，返回对象时触发移动或拷贝，语义清晰 - 调用方传入缓冲区：
void fill_buffer(char* out, size_t size)—— 内存所有权明确，无泄漏无竞争 - 堆上分配 + 明确契约：
char* make_string()必须文档注明“调用方负责free”，且实际用malloc或new分配
最容易被忽略的一点：即使你用 static 避开了崩溃，只要函数可能被多个线程同时调用，或者被递归调用，那个“看起来能跑”的代码就已经埋下了非确定性 bug。真正的安全，从来不是“没崩”，而是“不可能崩”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
