先从一个很常见的痛点说起事件分发代码写成十来个 if-else 一本道产品经理再加一种事件类型就得顺着嵌套找该插在哪一层运营反馈某条线上规则顺序不对你还得靠肉眼对比提交记录才能确认链路的真实顺序。这时候“职责链模式”就会浮现在脑海里。但真正在 C 里落地时你会发现教科书上那个虚函数 setNext 的经典写法在现代 C 工程里用起来并不顺手——因为围绕“责任”这个词可以有完全不同的表达方式。这篇文章不打算复述教科书而是把我在几个内部项目里实际见过的、用过的职责链模式变体逐一拆开std::function 链、函数指针静态链、中间件洋葱链、状态机驱动链、编译期模板链、C20 协程链。它们解决的问题不同适用场景也完全不同看完你应该知道自己该选哪一种。1. 教科书职责链在 C 里的三处硬伤在讨论变体之前先把“最正统”的写法摆出来后面所有比较都基于它。经典职责链大致是这个样子class Handler { public: virtual ~Handler() default; void SetNext(std::shared_ptrHandler next) { next_ std::move(next); } void Handle(Request req) { if (CanHandle(req)) { Process(req); } else if (next_) { next_-Handle(req); } } private: virtual bool CanHandle(Request req) 0; virtual void Process(Request req) 0; std::shared_ptrHandler next_; };每个业务规则继承 Handler实现 CanHandle 和 Process调用方把节点按顺序串起来。这套设计在 C98 时代很流行但放在现代 C 工程里至少有三个问题让我越来越不愿意直接使用它。1.1 硬伤一一个规则一个类类数量先崩只要业务规则稍微多起来文件数量就跟着膨胀。一个订单事件要分“优惠计算、库存扣减、风控校验、消息通知”四个步骤我就要写四个类每个类哪怕只有十几行也得单独放一个头文件和实现文件。很多团队把职责链节点搞成十几个类最后发现真正变化的只是“谁能处理这个请求”的判断逻辑和“怎么处理”的十几行代码但因为继承自抽象基类被迫拆成了四个编译单元编译时间上去了代码跳转也绕远路。其实这里面的多数处理器用一个 lambda 就完全能表达清楚。1.2 硬伤二链路状态和上下文难以传递经典的 Handle 接口只有 Request 一个参数如果第三个处理器需要第二个处理器算出来的临时结果就只能在 Request 里塞字段。塞多了之后Request 变成了一个万能对象袋每个处理器往里塞自己关心的东西没人敢清理也没人知道哪些字段已经被消费完。更麻烦的是有的处理器需要向链尾传一个“我已经处理了一半你可以接着做后半段”的状态这个状态既不是“我能处理”也不是“我不能处理”而是一种中间语义。虚函数签名一旦固定扩展这种语义只能靠修改 Request 结构改一次依赖它的所有节点都可能受影响。1.3 硬伤三所有权的归属问题链条节点用 shared_ptr 串起来的时候所有权是共享的。调用方持有头节点每个节点又持有下一个节点整条链的生命周期看起来没问题但一旦业务逻辑里需要从中间插入或摘除节点shared_ptr 的引用计数会变得很难控制甚至可能出现链尾节点被外部继续持有导致整条链无法析构的隐性问题。换成 unique_ptr 可以解决所有权模糊但插删节点就得先拿到父节点的 raw pointer父节点被替换的瞬间链的一致性又需要额外维护。这个问题在经典写法里经常被忽略直到线上出现内存增长才回头排查。硬伤说白了就一句话经典职责链把“处理逻辑”和“处理节点”绑定得太死而 C 工程里恰恰希望两者尽可能解耦。下面要讲的变体本质上都是在解耦这件事上做了不同的取舍。2. 变体一std::function 运行时链与中间件洋葱模型2.1 用 std::function 打破继承绑定C11 之后std::function 让“处理器”不再必须是类对象只要可调用、返回 bool 就行了。于是职责链可以退化成非常简单的东西using HandlerFunc std::functionbool(Request); class HandlerChain { public: void Add(HandlerFunc h) { handlers_.push_back(std::move(h)); } void Handle(Request req) { for (auto const h : handlers_) { if (h(req)) { return; } } // 没有节点处理走兜底逻辑 } private: std::vectorHandlerFunc handlers_; };每个处理器变成 lambda想捕获什么状态就捕获什么想新增一个规则调用链对象的方法就行不需要新建类。这里 bool 的含义是“我处理完了链可以停了”返回 false 则继续往下传。对比虚函数版这个变体直接把继承层的所有成本全部去掉也因此成为我在大多数业务代码里的首选。工程上有个细节判断是否处理不要用简单的 true/false而是用一个 enum class 明确表达三种状态enum class HandleResult { Handled, // 已处理终止流转 Continue, // 我不处理继续给下一个 Rejected // 我发现了问题需要走异常分支 };True/false 在早期够用但当某个处理器确实“发现了请求有严重问题需要中断整条链”却又要区别于“正常继续”的时候bool 就表达不过来了。改成枚举之后链路逻辑清楚得多也没有破坏原模式的核心思路。2.2 从线性责任链延伸到洋葱模型std::function 链很容易再做一层演进每个处理器不仅可以决定“继续/终止”还可以在调下一个节点之前和之后做事情。这变成了常见的中间件链也就是洋葱模型using Next std::functionvoid(); using Middleware std::functionvoid(Request, Next); class MiddlewareChain { public: void Use(Middleware mw) { middlewares_.push_back(std::move(mw)); } void Run(Request req) { RunAt(0, req); } private: void RunAt(std::size_t idx, Request req) { if (idx middlewares_.size()) { return; } auto mw middlewares_[idx]; mw(req, [this, idx, req]() { RunAt(idx 1, req); }); } std::vectorMiddleware middlewares_; };“洋葱”的意思是第一个中间件可以在调用下一个节点之前做前置处理也可以调用 Next 之后做后置处理。它和职责链底层共享同一个结构——责任沿链条传递区别在于每个节点不仅能“拦下请求”还能“包裹请求”。我在内部服务里见过用这套思想实现鉴权、日志、限流、业务处理一条链的场景加横切逻辑时不需要动业务节点体验远好于虚函数链。2.3 std::function 链在实战中的注意点std::function 链不是没有坑。它最大的隐藏开销是类型擦除每个函数都可能有一次小堆分配但更值得注意的是拷贝语义。lambda 捕获了一个 unique_ptr 或者内部用了 shared_ptr 时放进 std::function 没任何问题但如果处理器非常轻、调用频率极高用 std::function 包装一层间接调用的开销可能比业务本身还大——这种情况说明链上节点太小太密应该考虑合并节点或者换成下一节的静态链。另一个实战心得HandlerChain 的节点顺序一定要有清晰的插入点。直接给 Add 方法不加区分后面十六个节点都在一个函数里依次 Add很容易出现有人把新处理器插到不该出现的位置。我习惯让 Add 支持在指定位置插入void Add(HandlerFunc h); void InsertBefore(std::size_t pos, HandlerFunc h); void Remove(std::size_t pos);再配合一个std::vectorstd::string names_记录每个节点的名字日志里就能打出“当前责任链长度为 12处理路径Auth - Cache - Business - Done”这种信息线上排查问题会省非常多时间。3. 变体二手写 next 指针的低开销静态链3.1 函数指针节点的纯静态链std::function 灵活但有间接调用开销也依赖堆上的闭包。在嵌入式设备、高频实时路径或者对栈上分配极其敏感的环境里我见过一个更朴素的变体直接用函数指针 next 指针构成链表节点全部放静态存储区。struct HandlerNode { bool (*process)(Request); const char* name; const HandlerNode* next; bool Handle(Request req) const { if (process(req)) { return true; } if (next) { return next-Handle(req); } return false; } };建链方式也直接通过静态数组和指针互相指static bool StepC(Request) { /* ... */ return true; } static bool StepB(Request req) { if (req.status ! 2) { return false; } /* ... */ return true; } static bool StepA(Request req) { /* ... */ return false; } static const HandlerNode nodeC {StepC, step_c, nullptr}; static const HandlerNode nodeB {StepB, step_b, nodeC}; static const HandlerNode nodeA {StepA, step_a, nodeB};没有堆分配没有虚函数没有闭包甚至可以用在禁用异常和 RTTI 的环境里。每个节点就是一个名字 一个函数指针链路关系在编译期就能确定。3.2 一个适合嵌入式的建链技巧如果链是真正固定不变的还可以进一步把节点声明为 constexprconstexpr HandlerNode nodeC{StepC, step_c, nullptr}; constexpr HandlerNode nodeB{StepB, step_b, nodeC}; constexpr HandlerNode nodeA{StepA, step_a, nodeB};这样节点直接放在只读段的静态区连初始化开销都没有。处理器函数内部如果需要状态通常用一个全局上下文指针或者把状态塞进 Request 的某个字段——因为函数指针没有捕获能力这是静态链表达力的边界。如果有人想在没有捕获能力的前提下写一个“根据内部计数决定是否处理”的节点我只能建议多带一个上下文结构体参数而不是强行用静态链。3.3 低开销链的边界在哪里这条链最大的限制是递归调用。每个节点的 Handle 调用下一个节点的 Handle链长到一定程度就可能在递归深度上出问题。虽然大部分平台上几百层的递归栈还能扛得住但如果你面对的是硬件资源极少或者栈特别小的环境建议把递归改成显式循环bool HandleLoop(Request req) const { const HandlerNode* cur this; while (cur) { if (cur-process(req)) { return true; } cur cur-next; } return false; }改成循环之后链的长度不再影响栈深度也更容易观测“当前走到哪个节点”。在实际项目里我通常只在两种场景使用这个变体一是嵌入式环境里逻辑相对固定二是性能压测发现 std::function 链是关键热点。其余情况它表达力不足的缺点会很快显现出来。4. 变体三状态机驱动的责任流转链4.1 状态机视角下的责任转移传统职责链是一条直线节点 1 不处理传给节点 2节点 2 不处理传给节点 3。但真实业务里责任转移并不总是直线的。一个审批流主管审批通过后责任到经理经理打回后责任又回到提交人——这已经不是一个方向上的线性传递了。用线性职责链硬建模代码会变成一堆 if (state xxx) 手动改变 next 指针维护成本很高。于是有了状态机驱动的变体把“当前由谁处理责任”建模为状态把“判断应不应该转移责任”建模为转移函数。enum class NodeState { Start, NeedEdit, NeedManager, NeedDirector, Finished, Rejected }; using Transition std::functionNodeState(Request); class StateChain { public: void Register(NodeState from, Transition fn) { transitions_[from] std::move(fn); } NodeState Run(Request req, NodeState init) { NodeState cur init; for (int step 0; step max_steps_; step) { auto it transitions_.find(cur); if (it transitions_.end()) { return cur; } NodeState next it-second(req); if (next cur) { // 处理不了停在这里 return cur; } cur next; } throw std::runtime_error(state chain cycle detected); } private: std::unordered_mapNodeState, Transition transitions_; int max_steps_ 100; };这里的每个转移函数都像责任链里的一个节点它检查请求决定要不要把“责任”转移到另一个状态。区别在于后面接手的不一定是“下一个开发时顺序排列的节点”而是由业务状态语义指定的任意状态。这也正是它被称为职责链变体的原因——保留了责任的传递但打破了链必须是一条单向线性路径的限制。4.2 环形责任链的检测与上限状态机链最容易踩的坑是死循环状态 A 转移到 BB 又转移到 A请求在两者之间反复横跳。经典责任链不存在这个问题因为它天然是一条单链表状态机就不一样了。所以要让 Run 方法带一个步数上限超限直接抛异常并打日志把状态转移路径输出出来。我习惯在每个转移函数里顺带记录日志NodeState cur init; for (int step 0; step max_steps_; step) { auto next transitions_[cur](req); LOG(INFO) state chain: StateName(cur) - StateName(next); cur next; }这一步在排查“为什么审批流程卡住了”时价值巨大因为每条责任链都变成了可读的路径记录。4.3 状态机链适合怎样的业务最适合这种变体的是流程类业务而不是简单的事件分派。比如订单状态流转、审批流、协议握手流程。其中协议的每个阶段都有独立的处理函数阶段之间不是按“数组顺序”而是按“当前状态”推进而且有些协议在异常情况下需要回退到上一个阶段。用状态机链表达几乎就是把流程图画成了代码用线性职责链表达你会在 next 赋值上疲于奔命。要注意的是状态机链并没有完全替代职责链因为它的节点数量通常较少但每个节点的逻辑可能更重。我把这种变体定位成“具备状态路由能力的职责链”适合那个“链已经不成线”的重业务场景。5. 变体四编译期模板元编程链5.1 编译期递归展开if constexpr tuple如果一条责任链的节点在编译期就能完全确定并且绝不希望在运行期有动态分派和类型擦除成本那模板链就派上用场了。C17 的 if constexpr 加上 std::tuple可以写一个非常干净的编译期递归职责链template typename... Handlers class StaticChain { public: explicit StaticChain(Handlers... handlers) : handlers_(std::move(handlers)...) {} bool Handle(Request req) { return HandleImpl0(req); } private: template std::size_t I bool HandleImpl(Request req) { if constexpr (I sizeof...(Handlers)) { return false; // 链尾 } else { if (std::getI(handlers_)(req)) { return true; } return HandleImplI 1(req); } } std::tupleHandlers... handlers_; };使用方式很直白StaticChain chain{ [](Request req) - bool { if (req.type ! query_balance) return false; // 处理逻辑 return true; }, [](Request req) - bool { req.result default response; return true; }, }; Request req{...}; if (chain.Handle(req)) { // ... }处理器可以是一个 lambda可以是一个普通函数指针也可以是一个带有 operator() 的轻量结构体。模板参数包决定了链的静态顺序HandleImpl0先尝试第一个不行就递归尝试第二个直到参数包耗尽返回 false。5.2 模板链的优化效果这个变体最大的优势是零额外开销。没有堆分配没有 std::function 的间接调用没有虚表。由于每个节点的类型在编译期都是完整的编译器可以把整个递归调用优化成顺序执行甚至可以内联每个节点的逻辑。对于“每次请求都要经过五个处理器、每个处理器逻辑很短”的热路径模板链在优化后的性能往往能逼近手写顺序 if-else。从设计模式的角度理解这其实是“在编译期完成职责链的装配”。经典模式把链的构造推迟到运行期所以能动态调整模板链反向操作把链的装配提前到编译期换取了极致性能。5.3 模板链不可替代的场景模板链不只是在追求性能时才有价值。它在“处理器的顺序必须被编译器强制保证”的场景也很好用。比如协议解析里“先解包头再解负载再做校验”这三个步骤的顺序天然固定如果有人不小心在运行期把校验插到解包头之前整个协议流程就错了。用模板链顺序在类型里就写死了不存在运行期被人改错的可能。不过它也有明显的边界链一旦实例化运行期就无法动态插入节点。处理器之间如果需要共享可变状态也会比较拧巴因为 tuple 中每个处理器是各自独立的副本状态不会自动传递。想要共享得用 std::reference_wrapper 包住一个外部上下文把共享对象显式传给每个处理器。总之模板链适合“静态、固定、性能敏感”的场景不适合业务规则频繁变化的场景。6. 变体五基于 C20 协程的挂起传递链6.1 协程链的调用模型现代业务里越来越多处理节点需要等网络 IO、查数据库或者等待下游服务返回结果再决定要不要继续处理。经典职责链和前面几个变体默认处理器是同步阻塞的遇到 IO 就会把线程卡住。C20 协程提供了一种新玩法每个处理器是一个可以挂起/恢复的协程整条链的组织方式类似 std::function 链但 await 的引入让责任转移可以跨异步边界。这里先给一个简化的模型假设有某种协程任务类型 task using AsyncHandler std::functiontaskbool(Request); taskbool RunAsyncChain(std::vectorAsyncHandler chain, Request req) { for (auto handler : chain) { if (co_await handler(req)) { co_return true; } } co_return false; }每个处理器返回 task 在内部可以 co_await 网络请求、数据库查询等结果回来之后再判断“要不要处理这个请求”。调用方只看到整条链返回 true/false但链上每个节点可能在等 IO 时把线程释放掉这在高并发场景下比同步阻塞链有质的差别。6.2 让每个节点跨异步边界举个例子某条责任链第一个节点要查账户余额第二个节点要根据余额判断可以走哪个优惠活动。如果使用同步 std::function 链第一个节点必须阻塞等待数据库返回线程被白白占用用协程链的话taskbool BalanceHandler(Request req) { auto balance co_await query_balance(req.user_id); req.balance balance; co_return false; // 查完之后仍然交给下一个节点处理 } taskbool PromotionHandler(Request req) { if (req.balance 100) { req.promotion none; co_return true; } // 继续计算 co_return true; }这就是最强的地方责任链的模式结构没有变但每个节点在自己的挂起点处释放了线程。链的传递效率不再受 IO 阻塞影响。6.3 协程链的代价和需要守住的底线协程链也不是银弹。它的主要成本是协程帧每一个 co_await 都可能产生一次堆分配节点越多帧越多调用频率高起来之后需要做性能测算不能无脑把所有节点都变成协程。另一个需要注意的点是请求对象生命周期协程挂起期间Request 必须保证存活一般通过 shared_ptr 或值拷贝解决不能传一个栈上临时对象进去。还有一点让我在实际项目里吃过亏协程链的异常传播和经典链不同。如果在某个 handler 的协程体内抛异常异常会在 co_await 恢复点处重新抛出外层必须包 try-catch。所以协程链的每个 handler 最好明确规定“要么正常返回 bool要么抛异常统一走兜底”不要指望本地栈能像同步链那样自然 unwind。没有协程经验的团队建议先从 std::function 链起步等真的遇到同步阻塞撑不住的热点再局部改造成协程链。7. 六种变体在同一业务场景下的选型与切换成本7.1 一张对照表把六种变体放在一起比较感受会更直观变体运行期动态调整单次调用开销异步支持调试可观测性适用场景虚函数链中等可插入节点中等虚函数间接调用 shared_ptr 管理难需要自行封装一般类名可读老代码库、强面向对象体系std::function 链好vector 随时插删中类型擦除 可能的闭包分配仅同步较好可记录节点名大多数业务代码、服务端流程函数指针静态链差编译期固定极低纯函数调用仅同步好节点名可读嵌入式、固定协议、极致性能状态机链好注册表可热插拔中低哈希查表 function 调用可异步很好状态路径可打印审批流、协议握手、复杂流程模板链无编译期固定极低可内联无间接调用仅同步一般模板栈较深固定顺序的热路径、协议步骤协程链好vector 组织高协程帧分配每 await 一帧强可跨 IO 挂起较好调用栈可见IO 密集、节点需要异步等待7.2 我实际做选型的四步判断法没想清楚之前不要硬选。我自己的流程是四步走第一步问自己链上节点是否需要异步等待需要基本直接看协程链不需要继续往下。第二步问链路的顺序是否会在运行期频繁变化如果节点会随配置中心远程调整选 std::function 链或者状态机链。如果顺序完全绑定在代码里很少变模板链或静态链更香。第三步问处理器数量和调用频率。只有三五个处理器且调用频率极高用模板链处理器数量多且每个都比较重std::function 链的开销可以忽略不计灵活性更重要。第四步问业务流转是不是严格单向线性。如果存在回退、跳转、分支合并不要硬套责任链直接换成状态机链硬把线性链扭成非线性后面会越改越痛苦。这套判断方法在几个内部项目中已经验证过多次基本能避开 90% 的错误选择。7.3 别为了变体而变体值得多说一句的是设计模式的变体只是手段最终判断标准永远是“代码好不好改、线上好不好查”。我见过有人硬上模板链是因为觉得它“高级零开销”结果业务规则一个月变了三次每次都要改类型参数反而比 std::function 链慢得多也见过有人明明在写审批流程非要把状态机逻辑用一串 next 指针拼出来拼到后面自己都分不清哪条路径有效。选型的时候性能只是一部分权重变更频率、团队熟悉度、可观测性占到更重要的位置。最后的个人体会职责链不管怎么变体本质上都是“每个节点只回答一个问题——这事归不归我管”。std::function 只是把这个回答过程变成了一个 lambda 调用模板链则是把它推到了编译期协程链又给这个回答过程加了挂起点。模式骨架没有变变的是承载“责任”的介质。实际编码时我会先写一版最土的 std::function 链把行为稳定下来再用单元测试把“节点顺序、终止条件、上下文传递”全部固定之后才根据性能或者异步需求替换成其他变体。这个顺序建议你也试一试它替你省掉的不是代码量而是重构时最危险的不确定性。
先从一个很常见的痛点说起事件分发代码写成十来个 if-else 一本道产品经理再加一种事件类型就得顺着嵌套找该插在哪一层运营反馈某条线上规则顺序不对你还得靠肉眼对比提交记录才能确认链路的真实顺序。这时候“职责链模式”就会浮现在脑海里。但真正在 C 里落地时你会发现教科书上那个虚函数 setNext 的经典写法在现代 C 工程里用起来并不顺手——因为围绕“责任”这个词可以有完全不同的表达方式。这篇文章不打算复述教科书而是把我在几个内部项目里实际见过的、用过的职责链模式变体逐一拆开std::function 链、函数指针静态链、中间件洋葱链、状态机驱动链、编译期模板链、C20 协程链。它们解决的问题不同适用场景也完全不同看完你应该知道自己该选哪一种。1. 教科书职责链在 C 里的三处硬伤在讨论变体之前先把“最正统”的写法摆出来后面所有比较都基于它。经典职责链大致是这个样子class Handler { public: virtual ~Handler() default; void SetNext(std::shared_ptrHandler next) { next_ std::move(next); } void Handle(Request req) { if (CanHandle(req)) { Process(req); } else if (next_) { next_-Handle(req); } } private: virtual bool CanHandle(Request req) 0; virtual void Process(Request req) 0; std::shared_ptrHandler next_; };每个业务规则继承 Handler实现 CanHandle 和 Process调用方把节点按顺序串起来。这套设计在 C98 时代很流行但放在现代 C 工程里至少有三个问题让我越来越不愿意直接使用它。1.1 硬伤一一个规则一个类类数量先崩只要业务规则稍微多起来文件数量就跟着膨胀。一个订单事件要分“优惠计算、库存扣减、风控校验、消息通知”四个步骤我就要写四个类每个类哪怕只有十几行也得单独放一个头文件和实现文件。很多团队把职责链节点搞成十几个类最后发现真正变化的只是“谁能处理这个请求”的判断逻辑和“怎么处理”的十几行代码但因为继承自抽象基类被迫拆成了四个编译单元编译时间上去了代码跳转也绕远路。其实这里面的多数处理器用一个 lambda 就完全能表达清楚。1.2 硬伤二链路状态和上下文难以传递经典的 Handle 接口只有 Request 一个参数如果第三个处理器需要第二个处理器算出来的临时结果就只能在 Request 里塞字段。塞多了之后Request 变成了一个万能对象袋每个处理器往里塞自己关心的东西没人敢清理也没人知道哪些字段已经被消费完。更麻烦的是有的处理器需要向链尾传一个“我已经处理了一半你可以接着做后半段”的状态这个状态既不是“我能处理”也不是“我不能处理”而是一种中间语义。虚函数签名一旦固定扩展这种语义只能靠修改 Request 结构改一次依赖它的所有节点都可能受影响。1.3 硬伤三所有权的归属问题链条节点用 shared_ptr 串起来的时候所有权是共享的。调用方持有头节点每个节点又持有下一个节点整条链的生命周期看起来没问题但一旦业务逻辑里需要从中间插入或摘除节点shared_ptr 的引用计数会变得很难控制甚至可能出现链尾节点被外部继续持有导致整条链无法析构的隐性问题。换成 unique_ptr 可以解决所有权模糊但插删节点就得先拿到父节点的 raw pointer父节点被替换的瞬间链的一致性又需要额外维护。这个问题在经典写法里经常被忽略直到线上出现内存增长才回头排查。硬伤说白了就一句话经典职责链把“处理逻辑”和“处理节点”绑定得太死而 C 工程里恰恰希望两者尽可能解耦。下面要讲的变体本质上都是在解耦这件事上做了不同的取舍。2. 变体一std::function 运行时链与中间件洋葱模型2.1 用 std::function 打破继承绑定C11 之后std::function 让“处理器”不再必须是类对象只要可调用、返回 bool 就行了。于是职责链可以退化成非常简单的东西using HandlerFunc std::functionbool(Request); class HandlerChain { public: void Add(HandlerFunc h) { handlers_.push_back(std::move(h)); } void Handle(Request req) { for (auto const h : handlers_) { if (h(req)) { return; } } // 没有节点处理走兜底逻辑 } private: std::vectorHandlerFunc handlers_; };每个处理器变成 lambda想捕获什么状态就捕获什么想新增一个规则调用链对象的方法就行不需要新建类。这里 bool 的含义是“我处理完了链可以停了”返回 false 则继续往下传。对比虚函数版这个变体直接把继承层的所有成本全部去掉也因此成为我在大多数业务代码里的首选。工程上有个细节判断是否处理不要用简单的 true/false而是用一个 enum class 明确表达三种状态enum class HandleResult { Handled, // 已处理终止流转 Continue, // 我不处理继续给下一个 Rejected // 我发现了问题需要走异常分支 };True/false 在早期够用但当某个处理器确实“发现了请求有严重问题需要中断整条链”却又要区别于“正常继续”的时候bool 就表达不过来了。改成枚举之后链路逻辑清楚得多也没有破坏原模式的核心思路。2.2 从线性责任链延伸到洋葱模型std::function 链很容易再做一层演进每个处理器不仅可以决定“继续/终止”还可以在调下一个节点之前和之后做事情。这变成了常见的中间件链也就是洋葱模型using Next std::functionvoid(); using Middleware std::functionvoid(Request, Next); class MiddlewareChain { public: void Use(Middleware mw) { middlewares_.push_back(std::move(mw)); } void Run(Request req) { RunAt(0, req); } private: void RunAt(std::size_t idx, Request req) { if (idx middlewares_.size()) { return; } auto mw middlewares_[idx]; mw(req, [this, idx, req]() { RunAt(idx 1, req); }); } std::vectorMiddleware middlewares_; };“洋葱”的意思是第一个中间件可以在调用下一个节点之前做前置处理也可以调用 Next 之后做后置处理。它和职责链底层共享同一个结构——责任沿链条传递区别在于每个节点不仅能“拦下请求”还能“包裹请求”。我在内部服务里见过用这套思想实现鉴权、日志、限流、业务处理一条链的场景加横切逻辑时不需要动业务节点体验远好于虚函数链。2.3 std::function 链在实战中的注意点std::function 链不是没有坑。它最大的隐藏开销是类型擦除每个函数都可能有一次小堆分配但更值得注意的是拷贝语义。lambda 捕获了一个 unique_ptr 或者内部用了 shared_ptr 时放进 std::function 没任何问题但如果处理器非常轻、调用频率极高用 std::function 包装一层间接调用的开销可能比业务本身还大——这种情况说明链上节点太小太密应该考虑合并节点或者换成下一节的静态链。另一个实战心得HandlerChain 的节点顺序一定要有清晰的插入点。直接给 Add 方法不加区分后面十六个节点都在一个函数里依次 Add很容易出现有人把新处理器插到不该出现的位置。我习惯让 Add 支持在指定位置插入void Add(HandlerFunc h); void InsertBefore(std::size_t pos, HandlerFunc h); void Remove(std::size_t pos);再配合一个std::vectorstd::string names_记录每个节点的名字日志里就能打出“当前责任链长度为 12处理路径Auth - Cache - Business - Done”这种信息线上排查问题会省非常多时间。3. 变体二手写 next 指针的低开销静态链3.1 函数指针节点的纯静态链std::function 灵活但有间接调用开销也依赖堆上的闭包。在嵌入式设备、高频实时路径或者对栈上分配极其敏感的环境里我见过一个更朴素的变体直接用函数指针 next 指针构成链表节点全部放静态存储区。struct HandlerNode { bool (*process)(Request); const char* name; const HandlerNode* next; bool Handle(Request req) const { if (process(req)) { return true; } if (next) { return next-Handle(req); } return false; } };建链方式也直接通过静态数组和指针互相指static bool StepC(Request) { /* ... */ return true; } static bool StepB(Request req) { if (req.status ! 2) { return false; } /* ... */ return true; } static bool StepA(Request req) { /* ... */ return false; } static const HandlerNode nodeC {StepC, step_c, nullptr}; static const HandlerNode nodeB {StepB, step_b, nodeC}; static const HandlerNode nodeA {StepA, step_a, nodeB};没有堆分配没有虚函数没有闭包甚至可以用在禁用异常和 RTTI 的环境里。每个节点就是一个名字 一个函数指针链路关系在编译期就能确定。3.2 一个适合嵌入式的建链技巧如果链是真正固定不变的还可以进一步把节点声明为 constexprconstexpr HandlerNode nodeC{StepC, step_c, nullptr}; constexpr HandlerNode nodeB{StepB, step_b, nodeC}; constexpr HandlerNode nodeA{StepA, step_a, nodeB};这样节点直接放在只读段的静态区连初始化开销都没有。处理器函数内部如果需要状态通常用一个全局上下文指针或者把状态塞进 Request 的某个字段——因为函数指针没有捕获能力这是静态链表达力的边界。如果有人想在没有捕获能力的前提下写一个“根据内部计数决定是否处理”的节点我只能建议多带一个上下文结构体参数而不是强行用静态链。3.3 低开销链的边界在哪里这条链最大的限制是递归调用。每个节点的 Handle 调用下一个节点的 Handle链长到一定程度就可能在递归深度上出问题。虽然大部分平台上几百层的递归栈还能扛得住但如果你面对的是硬件资源极少或者栈特别小的环境建议把递归改成显式循环bool HandleLoop(Request req) const { const HandlerNode* cur this; while (cur) { if (cur-process(req)) { return true; } cur cur-next; } return false; }改成循环之后链的长度不再影响栈深度也更容易观测“当前走到哪个节点”。在实际项目里我通常只在两种场景使用这个变体一是嵌入式环境里逻辑相对固定二是性能压测发现 std::function 链是关键热点。其余情况它表达力不足的缺点会很快显现出来。4. 变体三状态机驱动的责任流转链4.1 状态机视角下的责任转移传统职责链是一条直线节点 1 不处理传给节点 2节点 2 不处理传给节点 3。但真实业务里责任转移并不总是直线的。一个审批流主管审批通过后责任到经理经理打回后责任又回到提交人——这已经不是一个方向上的线性传递了。用线性职责链硬建模代码会变成一堆 if (state xxx) 手动改变 next 指针维护成本很高。于是有了状态机驱动的变体把“当前由谁处理责任”建模为状态把“判断应不应该转移责任”建模为转移函数。enum class NodeState { Start, NeedEdit, NeedManager, NeedDirector, Finished, Rejected }; using Transition std::functionNodeState(Request); class StateChain { public: void Register(NodeState from, Transition fn) { transitions_[from] std::move(fn); } NodeState Run(Request req, NodeState init) { NodeState cur init; for (int step 0; step max_steps_; step) { auto it transitions_.find(cur); if (it transitions_.end()) { return cur; } NodeState next it-second(req); if (next cur) { // 处理不了停在这里 return cur; } cur next; } throw std::runtime_error(state chain cycle detected); } private: std::unordered_mapNodeState, Transition transitions_; int max_steps_ 100; };这里的每个转移函数都像责任链里的一个节点它检查请求决定要不要把“责任”转移到另一个状态。区别在于后面接手的不一定是“下一个开发时顺序排列的节点”而是由业务状态语义指定的任意状态。这也正是它被称为职责链变体的原因——保留了责任的传递但打破了链必须是一条单向线性路径的限制。4.2 环形责任链的检测与上限状态机链最容易踩的坑是死循环状态 A 转移到 BB 又转移到 A请求在两者之间反复横跳。经典责任链不存在这个问题因为它天然是一条单链表状态机就不一样了。所以要让 Run 方法带一个步数上限超限直接抛异常并打日志把状态转移路径输出出来。我习惯在每个转移函数里顺带记录日志NodeState cur init; for (int step 0; step max_steps_; step) { auto next transitions_[cur](req); LOG(INFO) state chain: StateName(cur) - StateName(next); cur next; }这一步在排查“为什么审批流程卡住了”时价值巨大因为每条责任链都变成了可读的路径记录。4.3 状态机链适合怎样的业务最适合这种变体的是流程类业务而不是简单的事件分派。比如订单状态流转、审批流、协议握手流程。其中协议的每个阶段都有独立的处理函数阶段之间不是按“数组顺序”而是按“当前状态”推进而且有些协议在异常情况下需要回退到上一个阶段。用状态机链表达几乎就是把流程图画成了代码用线性职责链表达你会在 next 赋值上疲于奔命。要注意的是状态机链并没有完全替代职责链因为它的节点数量通常较少但每个节点的逻辑可能更重。我把这种变体定位成“具备状态路由能力的职责链”适合那个“链已经不成线”的重业务场景。5. 变体四编译期模板元编程链5.1 编译期递归展开if constexpr tuple如果一条责任链的节点在编译期就能完全确定并且绝不希望在运行期有动态分派和类型擦除成本那模板链就派上用场了。C17 的 if constexpr 加上 std::tuple可以写一个非常干净的编译期递归职责链template typename... Handlers class StaticChain { public: explicit StaticChain(Handlers... handlers) : handlers_(std::move(handlers)...) {} bool Handle(Request req) { return HandleImpl0(req); } private: template std::size_t I bool HandleImpl(Request req) { if constexpr (I sizeof...(Handlers)) { return false; // 链尾 } else { if (std::getI(handlers_)(req)) { return true; } return HandleImplI 1(req); } } std::tupleHandlers... handlers_; };使用方式很直白StaticChain chain{ [](Request req) - bool { if (req.type ! query_balance) return false; // 处理逻辑 return true; }, [](Request req) - bool { req.result default response; return true; }, }; Request req{...}; if (chain.Handle(req)) { // ... }处理器可以是一个 lambda可以是一个普通函数指针也可以是一个带有 operator() 的轻量结构体。模板参数包决定了链的静态顺序HandleImpl0先尝试第一个不行就递归尝试第二个直到参数包耗尽返回 false。5.2 模板链的优化效果这个变体最大的优势是零额外开销。没有堆分配没有 std::function 的间接调用没有虚表。由于每个节点的类型在编译期都是完整的编译器可以把整个递归调用优化成顺序执行甚至可以内联每个节点的逻辑。对于“每次请求都要经过五个处理器、每个处理器逻辑很短”的热路径模板链在优化后的性能往往能逼近手写顺序 if-else。从设计模式的角度理解这其实是“在编译期完成职责链的装配”。经典模式把链的构造推迟到运行期所以能动态调整模板链反向操作把链的装配提前到编译期换取了极致性能。5.3 模板链不可替代的场景模板链不只是在追求性能时才有价值。它在“处理器的顺序必须被编译器强制保证”的场景也很好用。比如协议解析里“先解包头再解负载再做校验”这三个步骤的顺序天然固定如果有人不小心在运行期把校验插到解包头之前整个协议流程就错了。用模板链顺序在类型里就写死了不存在运行期被人改错的可能。不过它也有明显的边界链一旦实例化运行期就无法动态插入节点。处理器之间如果需要共享可变状态也会比较拧巴因为 tuple 中每个处理器是各自独立的副本状态不会自动传递。想要共享得用 std::reference_wrapper 包住一个外部上下文把共享对象显式传给每个处理器。总之模板链适合“静态、固定、性能敏感”的场景不适合业务规则频繁变化的场景。6. 变体五基于 C20 协程的挂起传递链6.1 协程链的调用模型现代业务里越来越多处理节点需要等网络 IO、查数据库或者等待下游服务返回结果再决定要不要继续处理。经典职责链和前面几个变体默认处理器是同步阻塞的遇到 IO 就会把线程卡住。C20 协程提供了一种新玩法每个处理器是一个可以挂起/恢复的协程整条链的组织方式类似 std::function 链但 await 的引入让责任转移可以跨异步边界。这里先给一个简化的模型假设有某种协程任务类型 task using AsyncHandler std::functiontaskbool(Request); taskbool RunAsyncChain(std::vectorAsyncHandler chain, Request req) { for (auto handler : chain) { if (co_await handler(req)) { co_return true; } } co_return false; }每个处理器返回 task 在内部可以 co_await 网络请求、数据库查询等结果回来之后再判断“要不要处理这个请求”。调用方只看到整条链返回 true/false但链上每个节点可能在等 IO 时把线程释放掉这在高并发场景下比同步阻塞链有质的差别。6.2 让每个节点跨异步边界举个例子某条责任链第一个节点要查账户余额第二个节点要根据余额判断可以走哪个优惠活动。如果使用同步 std::function 链第一个节点必须阻塞等待数据库返回线程被白白占用用协程链的话taskbool BalanceHandler(Request req) { auto balance co_await query_balance(req.user_id); req.balance balance; co_return false; // 查完之后仍然交给下一个节点处理 } taskbool PromotionHandler(Request req) { if (req.balance 100) { req.promotion none; co_return true; } // 继续计算 co_return true; }这就是最强的地方责任链的模式结构没有变但每个节点在自己的挂起点处释放了线程。链的传递效率不再受 IO 阻塞影响。6.3 协程链的代价和需要守住的底线协程链也不是银弹。它的主要成本是协程帧每一个 co_await 都可能产生一次堆分配节点越多帧越多调用频率高起来之后需要做性能测算不能无脑把所有节点都变成协程。另一个需要注意的点是请求对象生命周期协程挂起期间Request 必须保证存活一般通过 shared_ptr 或值拷贝解决不能传一个栈上临时对象进去。还有一点让我在实际项目里吃过亏协程链的异常传播和经典链不同。如果在某个 handler 的协程体内抛异常异常会在 co_await 恢复点处重新抛出外层必须包 try-catch。所以协程链的每个 handler 最好明确规定“要么正常返回 bool要么抛异常统一走兜底”不要指望本地栈能像同步链那样自然 unwind。没有协程经验的团队建议先从 std::function 链起步等真的遇到同步阻塞撑不住的热点再局部改造成协程链。7. 六种变体在同一业务场景下的选型与切换成本7.1 一张对照表把六种变体放在一起比较感受会更直观变体运行期动态调整单次调用开销异步支持调试可观测性适用场景虚函数链中等可插入节点中等虚函数间接调用 shared_ptr 管理难需要自行封装一般类名可读老代码库、强面向对象体系std::function 链好vector 随时插删中类型擦除 可能的闭包分配仅同步较好可记录节点名大多数业务代码、服务端流程函数指针静态链差编译期固定极低纯函数调用仅同步好节点名可读嵌入式、固定协议、极致性能状态机链好注册表可热插拔中低哈希查表 function 调用可异步很好状态路径可打印审批流、协议握手、复杂流程模板链无编译期固定极低可内联无间接调用仅同步一般模板栈较深固定顺序的热路径、协议步骤协程链好vector 组织高协程帧分配每 await 一帧强可跨 IO 挂起较好调用栈可见IO 密集、节点需要异步等待7.2 我实际做选型的四步判断法没想清楚之前不要硬选。我自己的流程是四步走第一步问自己链上节点是否需要异步等待需要基本直接看协程链不需要继续往下。第二步问链路的顺序是否会在运行期频繁变化如果节点会随配置中心远程调整选 std::function 链或者状态机链。如果顺序完全绑定在代码里很少变模板链或静态链更香。第三步问处理器数量和调用频率。只有三五个处理器且调用频率极高用模板链处理器数量多且每个都比较重std::function 链的开销可以忽略不计灵活性更重要。第四步问业务流转是不是严格单向线性。如果存在回退、跳转、分支合并不要硬套责任链直接换成状态机链硬把线性链扭成非线性后面会越改越痛苦。这套判断方法在几个内部项目中已经验证过多次基本能避开 90% 的错误选择。7.3 别为了变体而变体值得多说一句的是设计模式的变体只是手段最终判断标准永远是“代码好不好改、线上好不好查”。我见过有人硬上模板链是因为觉得它“高级零开销”结果业务规则一个月变了三次每次都要改类型参数反而比 std::function 链慢得多也见过有人明明在写审批流程非要把状态机逻辑用一串 next 指针拼出来拼到后面自己都分不清哪条路径有效。选型的时候性能只是一部分权重变更频率、团队熟悉度、可观测性占到更重要的位置。最后的个人体会职责链不管怎么变体本质上都是“每个节点只回答一个问题——这事归不归我管”。std::function 只是把这个回答过程变成了一个 lambda 调用模板链则是把它推到了编译期协程链又给这个回答过程加了挂起点。模式骨架没有变变的是承载“责任”的介质。实际编码时我会先写一版最土的 std::function 链把行为稳定下来再用单元测试把“节点顺序、终止条件、上下文传递”全部固定之后才根据性能或者异步需求替换成其他变体。这个顺序建议你也试一试它替你省掉的不是代码量而是重构时最危险的不确定性。
