结构体更适合多值返回，因其支持命名、扩展性和移动语义；tuple仅适合临时数据组合，缺乏可读性与可维护性。
用结构体返回多个值时，别忘了移动语义
结构体是最直观的多值返回方式，但容易忽略拷贝开销。如果返回的是大对象（比如含 std::vector 或 std::string 的结构体），默认拷贝可能拖慢性能。
- 定义结构体时，确保成员支持移动（如使用
std::string而非const char*） - 函数返回时直接构造临时对象：
return {val1, val2, std::move(large_data)}; - 调用方用
auto result = get_user_info();，避免写死类型，让编译器推导并启用移动 - 若结构体仅作返回载体、无业务含义，别加构造函数或成员函数——否则可能抑制 NRVO 或强制拷贝
用 std::tuple 返回时，解包比想象中麻烦
std::tuple 灵活，但 C++17 之前没法直接结构化绑定，容易写出冗长又易错的代码。
- C++17 起推荐用结构化绑定：
auto [id, name, active] = get_user_tuple();，但注意变量顺序必须和tuple类型顺序严格一致 - 别用
std::get(t)按索引取值——一旦 tuple 成员增减，所有get<n></n>都得手动改，且无编译期语义检查 - tuple 类型名难读：
std::tuple<int std::string bool></int>不如结构体自解释；若需日志或调试，结构体字段名天然可读 - 函数签名里暴露
tuple会降低接口可维护性——后续想加默认值或重载，比结构体更受限
结构体 vs tuple：选哪个，看是否需要命名和扩展性
这不是语法选择题，而是接口设计问题。关键在“这个组合值以后会不会被复用、校验、序列化”。
- 如果多个函数都返回“用户ID+状态+最后登录时间”，就该定义
struct UserSummary——后续加to_json()或validate()更自然 - 如果只是临时拼凑两个计算结果（比如
std::pair<double double></double>表示坐标），std::tuple或std::pair更轻量 - 结构体支持隐式转换、友元函数、
constexpr构造；tuple 几乎只适合“装数据+拆数据”这一条路 - 跨模块传递时，结构体头文件依赖明确；tuple 容易因模板实例化导致 ODR 问题或链接失败（尤其涉及不同编译单元的
std::tuple<...></...>）
别忽略返回引用或指针的陷阱
有人想“高效”返回多个值，试图返回局部结构体的引用或 tuple&，这会导致悬垂引用。
立即学习“C++免费学习笔记（深入）”；
- 永远不要返回局部变量的引用或指针——无论结构体还是 tuple
- 若底层数据已存在且生命周期可控（如类成员），可返回
const User&，但这时“多个值”其实是视图，不是新构造 - 用
std::optional<:tuple>></:tuple>表达可能失败的多值返回，比裸 tuple + 布尔返回码更安全 - 函数内 new 出的 tuple？别这么做。C++ 不靠裸指针管理多值返回的生命周期
