最安全的选择是直接返回 std::vector，因其语义清晰、自动内存管理、支持移动语义且避免悬空指针；固定大小优先用 std::array，动态长度必须用 std::vector，禁用裸指针返回。
直接返回 std::vector 是最安全的选择
C++ 函数里想“返回数组”，本质是返回一块连续、可访问的数据。用 std::vector 不仅语义清晰，还能自动管理内存，避免悬空指针和内存泄漏。std::vector 支持移动语义（C++11 起），返回时通常不触发深拷贝，性能足够好。
常见错误现象：return arr;（局部 C 风格数组）、return &arr[0];（返回局部数组地址）——函数一结束，内存就失效，调用方拿到的是野指针。
- 永远不要返回局部
int arr[5];或std::array的地址（除非明确用static，但会破坏线程安全和多次调用语义） - 如果函数逻辑天然产出固定大小数据，优先用
std::array<t n></t>，它可值返回，且不带堆分配开销 - 需要动态长度？必须用
std::vector；别为了“省一次分配”而手写裸指针 +new—— 那等于把delete的责任甩给调用方，极易出错
std::vector 返回值在不同编译器下的行为一致吗
是的。C++11 标准规定：当函数返回一个局部 std::vector 对象时，编译器必须优先尝试移动构造（调用移动构造函数），失败才退化为拷贝。主流编译器（GCC、Clang、MSVC）都严格遵循，且开启优化（-O2）后，移动也常被进一步省略（RVO/NRVO）。
容易踩的坑：std::vector 的移动构造是 O(1)，但如果你在返回前调用了 v.shrink_to_fit() 或手动 reserve 又没用上，反而可能触发多余分配。
立即学习“C++免费学习笔记（深入）”；
- 不用手动写
std::move(v)返回 —— 编译器能自动识别具名右值引用场景（Named RVO 限制除外，但极少影响实际代码） - 若函数内反复修改 vector 大小（如循环 push_back），考虑提前
reserve()避免多次重分配 - 跨 DLL/so 边界返回
std::vector有 ABI 风险（尤其 MSVC 不同运行时版本），此时应改用输出参数或纯 C 接口
什么时候非得用裸指针 + 长度返回
极少数情况：对接 C API、嵌入式受限环境、或性能极端敏感且 profiler 确认 vector 构造/析构是瓶颈。这时不能返回栈数组，也不能返回 new 出来的裸指针（谁 delete？），正确做法是返回 std::unique_ptr<t></t> 或封装好的视图类型。
典型错误：int* func() { int* p = new int[10]; return p; } —— 调用方必须记住 delete[]，且无法表达长度信息，极易越界。
- 若必须交付原始指针，用
std::unique_ptr<int></int>包裹，调用方可通过.get()拿指针，长度需额外传参或靠约定（如末尾哨兵） - 更推荐
std::span<const int></const>（C++20）或gsl::span（C++17 前），它只存指针+长度，零开销，且明确表达“只读视图”意图 - 永远不要返回
std::shared_ptr<int></int>除非真需要共享所有权 —— 引用计数开销和生命周期复杂性往往得不偿失
返回 std::vector 时 size/capacity 怎么控制
返回前是否调用 shrink_to_fit() 或 resize()，取决于调用方后续是否频繁增删。vector 的 capacity 是实现细节，不应作为接口契约暴露。
常见误判：以为 “返回前 shrink_to_fit() 能节省内存”，其实只是释放多余 capacity；若调用方马上要 push_back 十几次，反而导致多次重分配。
- 如果函数逻辑确定最终大小（如从文件读取 N 行），用
std::vector<t>(n)</t>构造 +operator[]赋值，避免 push_back 触发扩容 - 如果中间过程不确定大小，但最终结果稳定，返回前调用
v.shrink_to_fit()合理；但注意它不保证一定释放内存（是 hint） - 别依赖
v.capacity()做业务判断 —— 它不是接口语义的一部分，不同标准库实现差异大
最复杂的点其实不在语法：在于你得想清楚——这个“数组”是临时计算结果，还是会被长期持有并继续修改？前者无脑 vector，后者得看持有方是否需要控制内存布局或分配器。这些决策藏在需求里，而不是 return 那一行代码里。
