责任链接口设计核心是解耦：处理器仅依赖抽象Handler，handle为纯虚函数，setNext返回Handler*支持链式调用且next_私有；需手动判空避免崩溃；生命周期须用shared_ptr管理防悬垂指针；基类不默认转发，由子类显式控制流程。
责任链接口怎么设计才不耦合后续实现
核心是让每个处理器只依赖抽象，不依赖具体类。必须把 handle 声明为纯虚函数，并提供 setNext 接口用于动态拼接——但注意，setNext 返回 void 会破坏链式调用；想写成 a->setNext(b)->setNext(c) 这种形式，返回类型得是 Handler* 或引用。
常见错误是把 next 指针暴露给外部直接赋值，导致调用方意外绕过 setNext 的空值检查或生命周期管理逻辑。正确做法是把 next_ 设为 private，只通过受控的 setNext 修改。
示例接口骨架：
class Handler {
public:
virtual ~Handler() = default;
virtual bool handle(const std::string& req) = 0;
Handler* setNext(Handler* next) {
next_ = next;
return next_;
}
protected:
Handler* next_ = nullptr;
};
为什么链式调用里要手动检查 next_ 是否为空
因为 C++ 没有像 Java 的 Optional 或 Rust 的 Option 那样强制解引用前校验的机制。一旦 next_->handle(req) 中 next_ 是 nullptr，程序直接崩溃，且堆栈里看不到责任链上下文，debug 成本高。
必须在每个 handle 实现里显式判断：
- 当前处理器不处理时，先判
if (next_)再调用next_->handle(req) - 如果当前处理器已处理完毕（比如返回
true表示终止传播），就不该再调用next_ - 不要依赖构造时“一定设置了 next”，运行时链可能被动态截断
漏掉这个检查，上线后遇到某个环节没挂上处理器，就是段错误或未定义行为。
如何避免 handler 对象生命周期导致的悬垂指针
责任链本质是对象间持有裸指针，而 C++ 不自动管理对象生存期。最典型的问题：链中某个 Handler 是栈对象或提前析构，后续调用 next_->handle() 就访问了释放内存。
解决方案只有两个，且必须选其一：
- 所有 handler 全部用
new分配 + 手动delete（适合短生命周期、明确控制权的场景） - 统一改用
std::shared_ptr<handler></handler>管理，setNext接收和存储智能指针，handle内部调用也通过shared_ptr转发（推荐，但要注意循环引用风险）
用 unique_ptr 不合适——链中任意节点不能独占所有权，否则无法共享给多个上游节点。
实际使用时要不要在基类里实现默认转发逻辑
可以，但仅限于“不处理就转发”这种通用行为。例如：
virtual bool handle(const std::string& req) override {
if (doHandle(req)) return true;
if (next_) return next_->handle(req);
return false; // 链尾未处理
}
但要注意：这个默认逻辑会掩盖子类是否真的需要定制转发行为。比如日志处理器可能无论是否处理都要记录，鉴权处理器可能在拒绝时抛异常而非返回 false。所以更稳妥的做法是基类只提供 doHandle 钩子，把转发决策完全留给子类——哪怕多写两行 if (next_) return next_->handle(...)，也比后期排查“为什么这里没进下一个 handler”强。
轻量级不是靠省代码实现的，是靠职责清晰、边界明确换来的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
