这是未定义行为，必须修改逻辑而非压制警告：返回局部变量引用必然悬垂，正确解法是改用值语义、调用方传入容器或智能指针托管堆对象。
直接结论：这不是警告，是编译器在救你命——返回局部变量的引用（或指针）必然导致悬垂，必须改逻辑，不能靠 suppress 或 static 临时顶替。
为什么 -Wreturn-local-addr 不是“可忽略的警告”
它对应的是未定义行为（UB），不是“可能出错”，而是“只要触发就不可预测”。哪怕程序看似正常输出，也只是运气好——栈内存还没被覆盖。真实服务中，这类问题常表现为：几小时后随机段错误、值偶尔错乱、ASan 报 use-after-scope、GDB 显示引用指向已析构对象地址。
常见误判点：
- 认为“只读不写就安全”：错。哪怕只读
ref.name，若对象已析构，name的内部指针（如std::string的小字符串缓冲区）可能已失效 - 认为“函数没被调用就没事”：错。编译器仍会检查所有可能路径；基类虚函数即使未被直接调用，链接期或 LTO 优化也可能暴露问题
- 用
static临时变量“快速修复”：错。它让所有调用共享同一份内存，破坏线程安全和对象独立性，且掩盖了设计缺陷
三种合法解法及适用场景
核心原则：引用/指针的生命周期必须 ≥ 使用它的上下文生命周期。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
改返回值为值语义（最常用）：
std::vector<int> fun()</int>。适用于返回数据量不大、移动成本可控的类型（std::vector、std::string等均有移动构造）。C++17 后 guaranteed copy elision 进一步消除开销 -
由调用方传入目标容器（推荐用于基类接口）：
void fun(std::vector<int>& out)</int>。避免所有权争议，调用方完全控制生命周期，派生类可直接填入自有成员objects -
用智能指针托管堆对象（需明确所有权）：
std::shared_ptr<:vector>> fun()</:vector>。适用于需要跨作用域共享、且能接受堆分配开销的场景；注意避免循环引用
容易踩坑的“伪修复”写法
这些写法看似绕过警告，实则引入更隐蔽的问题：
-
return const_cast<:vector>&>(std::vector<int>{})</int></:vector>：强制转换不改变对象生命周期，仍是悬垂 -
return *new std::vector<int></int>：返回堆对象的引用，但无处 delete，造成内存泄漏 -
std::vector<int>& fun() { static std::vector<int> v; return v; }</int></int>：多线程下v被所有线程共用，且无法支持多个不同实例 -
const char* f() { std::string s = "hello"; return s.c_str(); }：同理，s析构后c_str()失效，即使加const修饰也无效
真正难的不是语法怎么写，而是判断“这个引用到底该属于谁”。一旦把生命周期责任推给调用方却没在接口契约里写清楚（比如文档没说明“调用方必须保证传入对象存活至操作结束”），问题只是延迟爆发。
