直接返回String&会导致悬空引用，因为局部对象销毁后引用失效；正确做法是修改函数就地操作并返回*this，只读函数返回新String对象，配合移动语义优化性能。
为什么直接返回String&会导致悬空引用
链式调用（如 s.trim().to_upper().substr(0,5)）要求每个成员函数返回可继续调用的对象引用。但若函数内部创建临时对象（比如 return String{...}），再取其引用，就等于返回局部对象的引用——运行时行为未定义，常见表现是后续调用读到垃圾内存或崩溃。
典型错误写法：
String& to_upper() {
String result = ...; // 局部对象
return result; // ❌ 悬空引用
}- 所有修改类状态的函数（如
trim()、to_upper()）应就地修改*this并返回*this - 只读操作（如
substr()、find()）必须返回新对象（String值），不能返回引用 - 如果真要支持“非破坏性链式调用”，得靠返回值优化（RVO）或移动语义减少拷贝，而非强行返回引用
substr()这类工厂函数必须返回String而非String&
用户常误以为“链式”意味着所有函数都该返回引用，但 substr() 的语义是生成新字符串，不是修改原字符串。返回 String& 只有两种安全路径：要么返回 *this（不适用），要么返回某个长期存活对象的引用（无意义）。
正确实现示例：
立即学习“C++免费学习笔记（深入）”；
String substr(size_t pos, size_t len) const {
// 构造新String，依赖RVO或移动构造
return String{data_.substr(pos, len)};
}- 声明为
const成员函数，明确不修改自身 - 返回值类型是
String（非引用），调用方拿到的是独立对象，可继续链式调用其成员 - 确保
String类有移动构造函数，否则频繁链式调用会触发多次深拷贝
如何让trim()和to_upper()真正支持链式调用
这类函数本质是“修改自身 + 返回自身”，关键在于：不新建对象、不返回局部变量、不隐式转换。
标准写法：
String& trim() {
// 就地裁剪 data_
size_t start = 0, end = data_.size();
while (start < end && isspace(data_[start])) ++start;
while (end > start && isspace(data_[end-1])) --end;
data_ = data_.substr(start, end - start); // 注意：这里仍需赋值，但发生在成员变量上
return *this;
}
<p>String& to<em>upper() {
for (char& c : data</em>) c = toupper(static_cast<unsigned char>(c));
return *this;
}- 函数签名必须是
String& func()，且末尾写return *this; - 内部所有修改都作用于
this->data_（假设底层用std::string data_） - 避免在函数体内 new 或构造临时
String再返回其引用——这是最常踩的坑
移动语义对链式调用性能的实际影响
没有移动构造函数时，像 s.substr(0,10).to_upper() 这种写法会产生至少一次深拷贝（substr 返回值构造临时对象，再传给 to_upper 的隐式对象参数）。开启移动语义后，临时对象能被高效转移。
必须提供的移动接口：
String(String&& other) noexcept : data_(std::move(other.data_)) {}
String& operator=(String&& other) noexcept {
if (this != &other) data_ = std::move(other.data_);
return *this;
}- 移动构造和移动赋值都要标
noexcept，否则std::vector等容器可能退化为拷贝 -
substr()返回值会被编译器优先尝试移动，前提是类满足可移动条件 - 即使写了移动语义，也要注意：返回局部对象时，编译器通常启用 RVO，比移动还快；但链式中多层调用时，移动语义才真正起效
链式调用的实质不是语法糖，而是调用约定与对象生命周期的精确配合。最容易被忽略的，是混淆“就地修改”和“生成新值”这两类操作的返回类型——一个错，整条链就垮。
