必须用 const T& 而不是 T 传参的情形是：当参数为大对象（如 std::string、std::vector、自定义类）且函数只读不修改时，为避免拷贝开销；内置类型和小结构体则优先值传递。
什么时候必须用 const T& 而不是 T
当传入的参数是大对象（如 std::string、std::vector、自定义类）且函数只读不改时，const T& 是默认选择。值传递会触发拷贝构造，开销不可忽视——比如一个 1MB 的 std::vector，每次调用都拷贝就是实打实的内存与时间浪费。
常见错误是“图省事全用值传”，尤其在循环里调用时，性能陡降却难以察觉。注意：内置类型（int、double、指针）反而推荐值传递，因为引用本身在 x86-64 上通常也是 8 字节，无优势还多一次解引用。
-
std::string、std::vector、std::map等标准容器，一律优先const T& - 小结构体（如仅含 2 个
int）可测一下：若sizeof(T) ，值传更稳 - 函数签名暴露了是否修改参数语义：
void f(const std::string& s)表明不会动s，调用方更安心
输出参数该用 T& 还是 T*
现代 C++ 中，非空输出参数首选 T&；只有需要表达“可选输出”（即允许不提供）时，才考虑 T*。用指针容易模糊意图，也增加空指针检查负担。
典型反例：bool parse(const std::string& s, int* out_val) —— 调用方得传 &x，还可能误传 nullptr；而 bool parse(const std::string& s, int& out_val) 强制绑定有效变量，语义清晰，编译器也能更好优化。
立即学习“C++免费学习笔记（深入）”；
- 输出参数必须写入：用
T&，例如void split(const std::string&, std::vector<:string>& parts) - 输出参数可选（函数可能跳过写入）：用
T*，但需文档明确说明 null 合法 - 想同时支持输入+输出？别这么做。拆成两个参数或改用返回结构体（如
std::tuple或自定义struct）更安全
移动语义下，T&& 参数要不要加 const
不要加 const。写成 const T&& 会禁用移动操作，退化为只读右值引用，几乎无实用场景。真正需要的是完美转发或资源接管，此时必须是 T&&（非 const）。
典型误用出现在想“既接收右值又不修改”的场合——但右值本就预期被移动，加 const 只会让 std::move(x) 失效，编译器只能调用拷贝构造而非移动构造。
- 只用于转发：用
template+void f(U&& u) std::forward(u) - 只接收右值并移动：用
void f(T&& t)，内部调用t.some_expensive_operation()或std::move(t) - 如果函数逻辑上“只读右值”，说明它其实不该接受右值——应统一用
const T&
混合参数场景：一个函数既有输入又有输出，怎么组织
避免把输入和输出参数混在同一函数里，尤其是当它们生命周期或所有权关系不清晰时。C++ 没有标注“输入/输出”的语法糖，靠命名和顺序极易出错。
比如 bool transform(std::vector，调用方无法一眼看出 in_out 是被清空重填，还是追加，还是原地修改。更糟的是，若 config 内部持有对 in_out 的引用，就可能引发悬垂。
- 优先返回新对象：
std::vectortransform(const std::vector & input, const Config& c) - 若必须复用内存（如性能敏感循环），用明确命名的输出参数：
void transform_to(const std::vector& input, std::vector & output, const Config& c) - 绝不在同一参数上叠加输入+输出语义（即所谓“inout”参数），除非是极底层、有充分文档和测试保障的接口
最易被忽略的一点：参数顺序影响可读性。把 const 输入放前面，非常量输出放后面，符合从左到右“数据流”直觉。但这只是习惯，真正关键的是——每个参数的语义必须在函数名和类型中自解释，不能靠位置猜。
