链式调用要求每个函数返回当前对象的引用（myclass&）或指针，以支持连续调用；返回void、局部对象、值拷贝或类型不匹配均会破坏链式；builder模式是其最佳实践场景。
返回 this 指针是链式调用的前提
链式调用本质是让一次调用结束后还能继续调用下一个成员函数，这要求每个函数返回一个能继续点出成员函数的对象。对非静态成员函数来说，最直接的方式就是返回 this 指针（即当前对象的地址），但注意：必须返回 *this（对象本身）或 this（指针），而不能返回局部对象或值拷贝——否则后续调用会作用在临时对象上，无法修改原对象。
常见错误是写成 return *this; 却忘了函数返回类型声明为 MyClass&（引用），导致编译失败或静默切片；或者误写成 return this; 但声明为 MyClass 值类型，引发类型不匹配。
- 返回
MyClass&是最常用方式，支持修改原对象且无额外拷贝开销 - 若函数逻辑不允许修改对象（如只读查询），可返回
const MyClass&，但后续只能调用 const 成员函数 - 绝对不要返回局部对象、临时对象或栈上变量的引用/指针
void 返回类型彻底阻断链式调用
一旦某个成员函数声明为 void，它就无法参与链式调用——因为没有返回值可供下一次点操作。哪怕函数内部逻辑完全正确，只要返回类型是 void，链式表达式在语法上就非法。
例如：obj.setA(1).setB(2) 中，如果 setA 返回 void，编译器会报错类似 “void value not ignored as it ought to be”。
- 所有参与链式的函数必须统一返回引用（
MyClass&）或指针（MyClass*），保持调用链连贯 - 构造函数、析构函数、
operator=等特殊成员函数默认不支持链式，需显式重载并返回引用才能接入 - 注意运算符重载的返回类型一致性，比如
operator+=通常也应返回*this
const 成员函数与链式调用的兼容性问题
如果一个成员函数声明为 const，它只能被 const 对象或 const 引用调用；而链式调用中前一个函数返回的 const MyClass& 会限制后续可调用的函数范围——非 const 成员函数将不可见。
典型现象：代码 const Obj o; o.setA(1).setB(2); 编译不过，因为 setA 在 const 对象上调用后返回 const Obj&，导致 setB（非 const）无法调用。
- 若设计目标是“任意上下文都能链式”，所有链式函数都应是非 const 的，并返回非 const 引用
- 若需支持 const 场景（如只读配置构建），可提供 const 和 non-const 两组重载，但实际中更常见的是干脆不把链式接口用于 const 对象
- 返回
MyClass&&（右值引用）也可实现链式，但会移动语义介入，一般仅用于 builder 模式中明确放弃原对象所有权的场景
Builder 模式是链式调用最典型的落地场景
链式调用不是万能语法糖，它真正有价值的地方是提升可读性和减少中间变量，尤其适合配置类、构建器、流式 API（如日志、SQL 构造器）。C++ 中最稳妥的做法是把链式逻辑封装在独立的 Builder 类里，而非强行塞进业务实体。
例如：
class ConfigBuilder {
public:
ConfigBuilder& setHost(const std::string& h) { host_ = h; return *this; }
ConfigBuilder& setPort(int p) { port_ = p; return *this; }
Config build() const { return {host_, port_}; }
private:
std::string host_;
int port_;
};
// 使用
Config cfg = ConfigBuilder().setHost("localhost").setPort(8080).build();
这种写法规避了业务类被污染，也天然支持 const-correctness 和 move 优化。强行在核心数据类上堆砌链式接口，容易破坏单一职责，也让 const 接口设计变得棘手。
真正难的不是语法怎么写，而是判断哪些函数该链、哪些不该链——状态变更类操作适合链，副作用类（如 I/O、打印、提交）不适合链，否则会让调用者误以为它们是纯配置行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
