命令模式解耦请求结构，责任链模式解耦处理流程；前者封装请求为对象以支持撤销/排队，后者动态拼接处理器决定是否传递请求；混用需分层避免职责混乱。
命令模式的核心是「把请求封装成对象」
它让调用者（Invoker）不直接操作接收者（Receiver），而是通过 Command 对象间接触发行为。关键在于：每个 Command 实例都持有对具体接收者和具体动作的引用，且必须实现统一接口（如 execute()、undo()）。
常见错误是把 Command 写成纯函数式接口（比如只传 Runnable），丢失了状态保持能力——这样就无法支持撤销、重做、排队或日志记录。
实操建议：
-
Command类应包含接收者引用（不是静态工具类）、必要参数、以及可选的undo()实现 - 避免在
execute()里写业务逻辑分支；分支应由不同Command子类承担 - 如果命令需要异步执行，应在
Invoker层处理线程调度，而非塞进Command自身
public interface Command {
void execute();
void undo();
}
public class LightOnCommand implements Command {
private final Light light; // 接收者实例，非 static
public LightOnCommand(Light light) {
this.light = light;
}
@Override
public void execute() {
light.turnOn();
}
@Override
public void undo() {
light.turnOff();
}
}
责任链模式的核心是「动态拼接处理节点」
它让多个处理器（Handler）组成一条链，请求沿着链传递，每个节点决定是否处理、是否继续向下传。重点不在“谁处理”，而在“谁有权决定是否终止传递”。
立即学习“Java免费学习笔记（深入）”；
典型误用是把责任链写成固定顺序的 if-else if-else 链——这根本不是责任链，只是条件分支；真正的链必须支持运行时增删节点、跳过中间节点、甚至循环回溯（虽然不推荐）。
实操建议：
- 每个
Handler必须持有下一个Handler的引用（next），而不是靠外部硬编码顺序 - 不要在
handle()里直接 new 下一个 handler；链的组装应在客户端完成 - 警惕空指针：
next == null是链尾，不是 bug，应明确设计默认行为（如抛异常 / 返回空 / 记录告警）
public abstract class Handler {
protected Handler next;
public void setNext(Handler next) {
this.next = next;
}
public abstract void handle(Request request);
}
public class AuthHandler extends Handler {
@Override
public void handle(Request request) {
if (!request.isValidToken()) {
throw new SecurityException("Invalid token");
}
if (next != null) {
next.handle(request); // 明确委托，不隐式跳转
}
}
}
两者混用时最常踩的坑：链里塞命令，还是命令里藏链？
有人试图用责任链管理命令执行顺序（比如先校验、再持久化、最后发消息），结果把 Command 和 Handler 职责搅在一起：既想封装请求，又想控制流程走向。这时往往出现两个问题：
- 撤销逻辑失效：责任链中途断掉，前面已执行的
Command没法统一回滚 - 节点复用困难：一个
Handler如果同时承担命令执行和链路控制，就很难被其他场景复用
更合理的做法是分层：用责任链做前置拦截（权限、参数、限流），链末端才触发命令执行器；或者用命令队列 + 独立的责任链处理器来处理命令的生命周期事件（如“命令提交后通知审计模块”）。
真正难的不是写对单个模式，而是判断当前需求到底要解耦「请求结构」，还是要解耦「处理流程」——前者选命令，后者选责任链。边界模糊时，先画出调用时序图，看箭头是从谁指向谁、中间有没有可插拔的决策点。
