按值传递 std::string 在构造函数中通常更优，因能利用移动语义避免多余拷贝；仅当不保存且需零开销时才用 const 引用；std::string_view 不适用于需长期持有字符串的构造函数。
构造函数参数用 std::string 按值传递是否低效？
不一定低效，现代 C++（C++11 起）中按值传 std::string 往往比按 const 引用更优，前提是构造函数内部需要拥有该字符串的副本——这恰恰是绝大多数构造函数的真实需求。
原因在于：当调用方传入临时对象（如字面量 "hello"、返回 std::string 的函数调用）时，按值传递能触发移动语义；而 const 引用会强制绑定，失去移动机会，最终多一次拷贝。
- 按值：
MyClass(std::string s)→ 临时对象直接移动构造s - const 引用：
MyClass(const std::string& s)→ 临时对象仍需先构造再绑定，无法移动
什么时候必须用 const std::string&？
仅当你明确**不修改且不保存**该字符串，并且想避免任何构造开销（包括移动构造）时才考虑。典型场景极少，比如一个只做即时校验、不存字段的辅助函数。
对构造函数来说，几乎从不适用——因为构造函数的目的就是初始化成员，大概率要保存一份。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 若成员是
std::string m_name;，按值传参后可直接m_name = std::move(s);或直接初始化：MyClass(std::string s) : m_name(std::move(s)) {} - 若用
const std::string&，你得额外拷贝一次：m_name = s;（即使 s 是临时量，也逃不掉一次拷贝） - 若传入的是 C 风格字符串（如
"abc"），按值会走std::string的 char* 构造函数，按引用则需隐式构造临时对象再绑定——两者都构造，但按值后续还能移动，按引用只能拷贝
std::string_view 是不是更好？
不是通用替代方案。它零拷贝、轻量，但要求传入的字符数据生命周期**必须长于对象本身**。构造函数若把 std::string_view 存为成员或用于初始化 std::string 成员，就等于引入悬垂视图风险。
除非你设计的是只读、短期使用的上下文（如解析函数参数），否则在构造函数里用 std::string_view 做参数，往往只是把内存管理责任错误地推给调用方。
- 安全用法：
void parse(std::string_view sv)—— 立即使用，不保存 - 危险用法：
MyClass(std::string_view sv) : m_data(sv) {}——m_data是std::string_view，但sv可能指向栈上临时字符串 - 绕弯写法：
MyClass(std::string_view sv) : m_data(sv.data(), sv.size()) {}—— 本质又回到构造std::string，不如直接按值传
实际推荐写法与常见误判
主流现代写法就是按值传递 + 成员初始化移动，兼顾清晰性、性能和安全性。误判常来自过时经验（C++98 时代没移动语义）或混淆“避免拷贝”和“避免构造”。
- 正确：
Person(std::string name, std::string email) : m_name(std::move(name)), m_email(std::move(email)) {} - 冗余（且可能更慢）：
Person(const std::string& name, const std::string& email) : m_name(name), m_email(email) {} - 隐患：
Person(std::string_view name) : m_name(name) {}——std::string的string_view构造函数虽安全，但调用方若传std::string_view("lit")，底层仍依赖静态存储；一旦传std::string_view(s.c_str())且s生命周期短，就出问题
真正容易被忽略的点是：移动操作本身不是免费的——std::string 是否启用 small string optimization、堆分配状态、是否真的发生移动，都影响结果。但比起手动区分左值/右值重载，按值传递是最简单且平均表现最好的选择。
