【专题系列】搞定设计模式之—— 十六：责任链模式

Love The Way You Lie 2022-11-30 05:52 131阅读 0赞

点击上方“java大数据修炼之道”，选择“设为星标”

# 优质文章, 第一时间送达 #

###  ###

![format_png][]

![format_png 1][]

*  什么是责任链模式？
 *  为什么要用责任链模式
 *   *  不使用责任链模式
     *  引入责任链模式
 *  责任链模式优缺点
 *   *  责任链模式优点
     *  责任链模式缺点
 *  责任链模式应用场景

# 什么是责任链模式？ #

**职责链模式的定义：**

<table> 
 <tbody> 
  <tr> 
   <td>Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receiving objects and pass the request along the chain until an object handles it.（使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关 系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。）</td> 
  </tr> 
 </tbody> 
</table>

责任链模式的重点是在“链”上，由一条链去处理相似的请求在链中决定谁来处理这个请求，并返回相应的结果，

**通用类图如图16-1所示:**

图16-1:命令模式模式通用类图

![format_png 2][]

责任链模式的核心在“链”上，“链”是由多个处理者ConcreteHandler组成的，包含如下几个角色：

● Handler（抽象处理者）：

抽象处理者实现三个职责：

*  一是定义一个请求的处理方法handleMessage，唯一对外开放的方法；
 *  二是定义一个链的编排方法setNext，设置下一个处理者；
 *  三是定义了具体的请求者必须实现的两个方法：定义自己能够处理的级别getHandlerLevel和具体的处理任务echo。

public abstract class Handler {
    	private Handler nextHandler; // 每个处理者都必须对请求做出处理
    
    	public final Response handleMessage(Request request) {
    		Response response = null;
    		// 判断是否是自己的处理级别
    		if (this.getHandlerLevel().equals(request.getRequestLevel())) {
    			response = this.echo(request);
    		} else { // 不属于自己的处理级别
    					// 判断是否有下一个处理者
    			if (this.nextHandler != null) {
    				response = this.nextHandler.handleMessage(request);
    			} else {
    				// 没有适当的处理者，业务自行处理
    			}
    		}
    		return response;
    	}
    
    	// 设置下一个处理者是谁
    	public void setNext(Handler _handler) {
    		this.nextHandler = _handler;
    	}
    
    	// 每个处理者都有一个处理级别
    	protected abstract Level getHandlerLevel();
    
    	// 每个处理者都必须实现处理任务
    	protected abstract Response echo(Request request);
    }

在处理者中涉及三个类：Level类负责定义请求和处理级别，Request类负责封装请 求，Response负责封装链中返回的结果，该三个类都需要根据业务产生，可以在实际应用中完成相关的业务填充:

public class Level {
    	//定义一个请求和处理等级
    }
    
    public class Request {
    	//请求的等级
    	public Level getRequestLevel(){ return null; }
    }
    
    public class Response {
    	//处理者返回的数据
    }

● ConcreteHandler（具体处理者）:

public class ConcreteHandler1 extends Handler{
    
    	/**
    	 * 设置自己的处理级别
    	 */
    	@Override
    	protected Level getHandlerLevel() {
    		// TODO Auto-generated method stub
    		return null;
    	}
    
    	/**
    	 * 定义自己的处理逻辑
    	 */
    	@Override
    	protected Response echo(Request request) {
    		// TODO Auto-generated method stub
    		return null;
    	}
    
    }

定义了三个处理者，代码都是一样，此处不重复贴出。

● Client（客户端）：在客户端或高层模块中对链进行组装，并传递请求，返回结果。

public class Client {
    
    	/**
    	 * @param args
    	 */
    	public static void main(String[] args) {
    		//声明所有的处理节点
    		Handler handler1 = new ConcreteHandler1();
    		Handler handler2 = new ConcreteHandler2();
    		Handler handler3 = new ConcreteHandler3();
    		//设置链中的阶段顺序1-->2-->3
    		handler1.setNext(handler2);
    		handler2.setNext(handler3);
    		//提交请求，返回结果
    		Response response = handler1.handleMessage(new Request());
    	}
    
    }

在实际应用中，一般会有一个封装类对责任模式进行封装，也就是替代Client类，直接返回链中的第一个处理者，具体链的设置不需要高层次模块关系，这样，更简化了高层次模 块的调用，减少模块间的耦合，提高系统的灵活性。

# 为什么要用责任链模式 #

这里有一个业务场景，在万恶的封建社会，女子讲究“三从四德”，“三从”是指“未嫁从父、既嫁从夫、夫死从子”。

## 不使用责任链模式 ##

以批判的态度去分析这个业务场景，类图如下：

图16-2:腐朽的“三从”类图

![format_png 3][]  
IHandler是三个有决策权对象的接口，IWomen是女性的代码。下面是实现：

*  IWomen（妇女接口）：

public interface IWomen {
    	//获得个人状况
    	public int getType();
    	//获得个人请示
    	public String getRequest();
    }

*  Women（妇女实现类）：

public class Women implements IWomen{
    	/** 通过一个int类型的参数来描述妇女的个人状况 * 1--未出嫁 * 2--出嫁 * 3--夫死 */
    	private int type = 0;
    	// 妇女的请示
    	private String request = "";
    
    	// 构造函数传递过来请求
    	public Women(int _type, String _request) {
    		this.type = _type;
    		this.request = _request;
    	}
    
    	// 获得自己的状况
    	public int getType() {
    		return this.type;
    	}
    
    	// 获得妇女的请求
    	public String getRequest() {
    		return this.request;
    	}
    }

*  IHandler（有处理权的人员接口）：

public interface IHandler {
    	//一个女性（女儿、妻子或者母亲）要求逛街，你要处理这个请求
    	public void HandleMessage(IWomen women);
    }

*  实现类：有处理权的人对妇女的请求进行处理，分别有三个实现类，在女儿没有出嫁之前父亲是有决定权的；在女性出嫁后，丈夫有决定权；在女性丧偶后，对母亲提出的请求儿子有决定权；

public class Father implements IHandler {
    	// 未出嫁的女儿来请示父亲
    	public void HandleMessage(IWomen women) {
    		System.out.println("女儿的请示是：" + women.getRequest());
    		System.out.println("父亲的答复是:同意");
    	}
    }
    
    public class Husband implements IHandler {
    	// 妻子向丈夫请示
    	public void HandleMessage(IWomen women) {
    		System.out.println("妻子的请示是：" + women.getRequest());
    		System.out.println("丈夫的答复是：同意");
    	}
    }
    
    public class Son implements IHandler {
    	// 母亲向儿子请示
    	public void HandleMessage(IWomen women) {
    		System.out.println("母亲的请示是：" + women.getRequest());
    		System.out.println("儿子的答复是：同意");
    	}
    }

*  场景类：

public class Client {
    
    	public static void main(String[] args) {
    		// 随机挑选几个女性
    		Random rand = new Random();
    		ArrayList<IWomen> arrayList = new ArrayList();
    		for (int i = 0; i < 5; i++) {
    			arrayList.add(new Women(rand.nextInt(4), "看戏"));
    		}
    		// 定义三个请示对象
    		IHandler father = new Father();
    		IHandler husband = new Husband();
    		IHandler son = new Son();
    		for (IWomen women : arrayList) {
    			if (women.getType() == 1) {
    				// 未结婚少女，请示父亲
    				System.out.println("\n--------女儿向父亲请示-------");
    				father.HandleMessage(women);
    			} else if (women.getType() == 2) {
    				// 已婚少妇，请示丈夫
    				System.out.println("\n--------妻子向丈夫请示-------");
    				husband.HandleMessage(women);
    			} else if (women.getType() == 3) {
    				// 母亲请示儿子
    				System.out.println("\n--------母亲向儿子请示-------");
    				son.HandleMessage(women);
    			} else {
    				// 暂时什么也不做
    			}
    		}
    	}
    
    }

首先是通过随机方法产生了5个古代妇女的对象，然后看她们是如何就看戏这件事去请示的，运行结果如下：

![format_png 4][]

OK，业务已经实现了，但是明显这个业务实现是存在问题的。

● 职责界定不清晰  
对女儿提出的请示，应该在父亲类中做出决定，父亲有责任、有义务处理女儿的请示， 因此Father类应该是知道女儿的请求自己处理，而不是在Client类中进行组装出来，也就是说原本应该是父亲这个类做的事情抛给了其他类进行处理。

● 代码臃肿  
我们在Client类中写了if...else的判断条件，而且能随着能处理该类型的请示人员越多，if...else的判断就越多。

● 耦合过重  
这是什么意思呢，我们要根据Women的type来决定使用IHandler的那个实现类来处理请 求。有一个问题是：如果IHandler的实现类继续扩展怎么办？如果修改Client类，那就违背了开闭原则。

● 异常情况欠考虑  
妻子只能向丈夫请示吗？如果妻子（比如一个现代女性穿越到古代了，不懂什么“三从四德”）向自己的父亲请示了，父亲应该做何处理？我们的程序上可没有体现出来，逻辑失败了！

## 引入责任链模式 ##

针对上面的问题，这时候就该考虑引入责任链模式了。

可以抽象成这样一个结构，女性的请求先发送到父亲类，父亲类一看是自己要处理的，就 作出回应处理，如果女儿已经出嫁了，那就要把这个请求转发到女婿来处理，那女婿一旦去天国报道了，那就由儿子来处理这个请求，类似于如图16-3所示的顺序处理图：

图16-3:女性请示的顺序处理图

![format_png 5][]

父亲、丈夫、儿子每个节点有两个选择：要么承担责任，做出回应；要么把请求转发到后序环节。

根据责任链模式，修改后的类图如下：

图16-4:使用责任链模式后的女子“三从”类图

![format_png 6][]

实现如下：

*  改造后的Handler类：

public abstract class Handler {
    	public final static int FATHER_LEVEL_REQUEST = 1;
    	public final static int HUSBAND_LEVEL_REQUEST = 2;
    	public final static int SON_LEVEL_REQUEST = 3;
    	// 能处理的级别
    	private int level = 0;
    	// 责任传递，下一个人责任人是谁
    	private Handler nextHandler;
    
    	// 每个类都要说明一下自己能处理哪些请求
    	public Handler(int _level) {
    		this.level = _level;
    	}
    
    	// 一个女性（女儿、妻子或者是母亲）要求逛街，你要处理这个请求
    	public final void HandleMessage(IWomen women) {
    		if (women.getType() == this.level) {
    			this.response(women);
    		} else if (this.nextHandler != null) {
    			// 有后续环节，才把请求往后递送
    			this.nextHandler.HandleMessage(women);
    		} else {
    			// 已经没有后续处理人了，不用处理了
    			System.out.println("---没地方请示了，按不同意处理---\n");
    		}
    	}
    
    	/** 如果不属于你处理的请求，你应该让她找下一个环节的人，如女儿出嫁了， * 还向父亲请示是否可以逛街，那父亲就应该告诉女儿，应该找丈夫请示 */
    	public void setNext(Handler _handler) {
    		this.nextHandler = _handler;
    	}
    
    //有请示那当然要回应
    	protected abstract void response(IWomen women);
    }

在这里也用到模板方法模式，在模板方法中判断请求的级别和当前能够处理的级别，如果相同则调用基本方法，做出 反馈；如果不相等，则传递到下一个环节，由下一环节做出回应，如果已经达到环节结尾， 则直接做不同意处理。基本方法response需要各个实现类实现，每个实现类只要实现两个职 责：一是定义自己能够处理的等级级别；二是对请求做出回应。

三个实现类如下：三个实现类分别处理不同等级的请求

*  父亲类：

public class Father extends Handler {
    	// 父亲只处理女儿的请求
    	public Father() {
    		super(Handler.FATHER_LEVEL_REQUEST);
    	}
    
    	// 父亲的答复
    	protected void response(IWomen women) {
    		System.out.println("--------女儿向父亲请示-------");
    		System.out.println(women.getRequest());
    		System.out.println("父亲的答复是:同意\n");
    	}
    }

*  丈夫类：

public class Husband extends Handler {
    	// 丈夫只处理妻子的请求
    	public Husband() {
    		super(Handler.HUSBAND_LEVEL_REQUEST);
    	}
    
    //丈夫请示的答复
    	protected void response(IWomen women) {
    		System.out.println("--------妻子向丈夫请示-------");
    		System.out.println(women.getRequest());
    		System.out.println("丈夫的答复是：同意\n");
    	}
    }

*  儿子类：

public class Son extends Handler {
    	// 儿子只处理母亲的请求
    	public Son() {
    		super(Handler.SON_LEVEL_REQUEST);
    	}
    
    	// 儿子的答复
    	protected void response(IWomen women) {
    		System.out.println("--------母亲向儿子请示-------");
    		System.out.println(women.getRequest());
    		System.out.println("儿子的答复是：同意\n");
    	}
    }

*  Women类的接口没有任何变化
 *  实现类稍微有些变化：为了展示结果清晰一点，输出请求的来源

public class Women implements IWomen {
    	/**
    	 * 通过一个int类型的参数来描述妇女的个人状况 1--未出嫁 * 2--出嫁 * 3--夫死
    	 */
    	private int type = 0;
    	// 妇女的请示
    	private String request = "";
    
    	// 构造函数传递过来请求
    	public Women(int _type, String _request) {
    		this.type = _type; // 为了便于显示，在这里做了点处理
    		switch (this.type) {
    		case 1:
    			this.request = "女儿的请求是：" + _request;
    			break;
    		case 2:
    			this.request = "妻子的请求是：" + _request;
    			break;
    		case 3:
    			this.request = "母亲的请求是：" + _request;
    		}
    	}
    
    	// 获得自己的状况
    	public int getType() {
    		return this.type;
    	}
    
    	// 获得妇女的请求
    	public String getRequest() {
    		return this.request;
    	}
    }

*  场景类：

在Client中设置请求的传递顺序，先向父亲请示，不是父亲应该解决的问题，则由父亲 传递到丈夫类解决，若不是丈夫类解决的问题则传递到儿子类解决，最终的结果必然有一个 返回，其运行结果如下所示：

![format_png 7][]

业务调用类Client不用再去做判断到底是需要谁去处理，而且Handler抽象类的子类可以继续增加下去，只需要扩展传递链而已，调用类可以不用了解变化过程，甚至是谁在处理这个请求都不用知道。

# 责任链模式优缺点 #

## 责任链模式优点 ##

*  责任链模式使得一个对象无须知道是其他哪一个对象处理其请求，对象仅需知道该请求会 被处理即可，接收者和发送者都没有对方的明确信息，且链中的对象不需要知道链的结构， 由客户端负责链的创建，降低了系统的耦合度。
 *  请求处理对象仅需维持一个指向其后继者的引用，而不需要维持它对所有的候选处理者的 引用，可简化对象的相互连接。
 *  在给对象分派职责时，职责链可以给我们更多的灵活性，可以通过在运行时对该链进行动 态的增加或修改来增加或改变处理一个请求的职责。
 *  在系统中增加一个新的具体请求处理者时无须修改原有系统的代码，只需要在客户端重新 建链即可，从这一点来看是符合“开闭原则”的。

## 责任链模式缺点 ##

*  由于一个请求没有明确的接收者，那么就不能保证它一定会被处理，该请求可能一直到链 的末端都得不到处理；一个请求也可能因职责链没有被正确配置而得不到处理。
 *  对于比较长的职责链，请求的处理可能涉及到多个处理对象，系统性能将受到一定影响， 而且在进行代码调试时不太方便。
 *  如果建链不当，可能会造成循环调用，将导致系统陷入死循环。

# 责任链模式应用场景 #

在以下情况下可以考虑使用职责链模式：

*  有多个对象可以处理同一个请求，具体哪个对象处理该请求待运行时刻再确定，客户端只 需将请求提交到链上，而无须关心请求的处理对象是谁以及它是如何处理的。
 *  在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
 *  可动态指定一组对象处理请求，客户端可以动态创建职责链来处理请求，还可以改变链中 处理者之间的先后次序。

**参考：**

【1】：《设计模式之禅》  
【2】：《design-pattern-java》  
【3】：《研磨设计模式》

来源 | https://www.cnblogs.com/three-fighter/p/13238151.html 作者：三分恶

![format_png 8][]

**推荐学习路线：**

#### 1、[*java学习路线全攻略(资料、视频、源码、项目实战)*][java]  2、[【史上最强实战项目合集】java项目20套 +完整版java学习视频][java_20_ _java] ####

**推荐面试技巧：**

1、[面试时被质疑学历、年龄该怎么办？][Link 1]

2、[如何应对面试官问你职业规划问题][Link 2]

3、[面试的时候问：你的期望薪资多少？怎么谈？][Link 3]

4、[面试官问，你有什么问题需要问我的吗？][Link 4]

5、[*给培训出来的Java程序员的一点建议，教你如何找工作*][Java]

####  ####

**最近热文推荐：**

1、[看完这篇Redis缓存三大问题，保你能和面试官互扯。][Redis]

2、[Java中：如何把异常设计的更优雅？][Java 1]

3、[面试：SpringBoot中的条件注解底层是如何实现的？][SpringBoot]

4、[单怼多线程，60道面试题，你能答上几个？（附答案）][60]

5、[这21 个刁钻的HashMap 面试题，我把阿里面试官吊打了！][21 _HashMap]

6、[用 float 存储金额，老板说损失从工资里扣！][float]

7、[别用Date了，Java8新特性之日期处理，现在学会也不迟！][Date_Java8]

8、[*【收藏了】10分钟读懂进程线程、同步异步、阻塞非阻塞、并发并行*][10]

####  ####

注：加群要求 微信学习交流群：

> 1、想学习JAVA这一门技术， 对JAVA感兴趣零基础，想从事JAVA工作的。  
> 2、工作1-5年，感觉自己技术不行，想提升的  
> 3、如果没有工作经验，但基础非常扎实，想提升自己技术的。  
> 4、还有就是想一起交流学习的。  
>

小编个人微信

![format_png 9][]

(如果你有学习上不懂的问题、需要学习视频资源等;都可长按识别上方二维码添加小编为好友, 我将免费为你提供完整的学习路线和各种视频学习资源)

如果您觉得不错，请别忘了转发、分享、点赞让更多的人去学习， 您的举手之劳，就是对小编最好的支持，非常感谢！

> 如何您想进技术群交流，关注公众号在后台回复 “加群”，或者 “学习” 即可
> 
> 著作权归作者所有，欢迎大家投稿 (投稿作者我会在公众号一一署名一并感谢
> 
> 要加群的赶紧上车![format_png 10][]![format_png 10][]![format_png 10][]，请加我微信2782278837统一拉群

**![format_png 11][]**

***—写文不易，你的转发就是对我最大的支持—***

--------------------

**看完本文有收获？请转发分享给更多有需要的人**

####  ####

关注 java大数据修炼之道

每天学习java技术，你想学的Java知识这里都有！

![format_png 12][]

微信扫描二维码，关注我的公众号

写留言

![format_png 13][]

喜欢就给个“**在看![format_png 14][]**”

[format_png]: /images/20221124/7b43811a13de43769cc6be62b0597dda.png
[format_png 1]: /images/20221124/0cb2c2cdf8ba4566a62dca6f86138edc.png
[format_png 2]: /images/20221124/261fc660d9604edd86da02b1d7246be3.png
[format_png 3]: /images/20221124/f4d59778bc1c444ca8f26a5ae86edafa.png
[format_png 4]: /images/20221124/4fb43a759c3049ad8b2d7694d7e9f2a1.png
[format_png 5]: /images/20221124/8b50f6ce4e30450b9992b5149a03b5c7.png
[format_png 6]: /images/20221124/0096c805efda4831986ee7d65f43c7a6.png
[format_png 7]: /images/20221124/d84a6092585f4b22bfec0b2ca29bbd38.png
[format_png 8]: /images/20221124/0924ff7f50f04bfba62900ea8c5e4820.png
[java]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1cfbeccb646a83ac13e324f5ca70ecd01f688bd810dcd229cccdde88b3690eb182a94bae6&idx=1&mid=2247483762&scene=21&sn=8d0fd837e7c868b2f77127a64d2260cc#wechat_redirect
[java_20_ _java]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1cb6cccb6427abba16e35141d514f611d4bad664e20035b0d6514cf75cf747f0b0c54641b&idx=1&mid=2247484832&scene=21&sn=76f34dcd6696bdf4632b78855486d896#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1c8c6ccb641d0dc00120f62cd2cc3da873c6648e5401823564048bda77b76f685e0568c53&idx=1&mid=2247484938&scene=21&sn=b3fb2a265c02f824771ee19aceb64224#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1cb07ccb64211c9302f4b48ba92a7a16ef97c5706a44a84286ca414ab3ed7f4513bbc43d3&idx=1&mid=2247484875&scene=21&sn=c24484d48517e98235057fc80eac50d6#wechat_redirect
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1cbcbccb642ddcc2720cfa34af7d0b8eb5eca82b538c97327b75fbd48ff305fe7a4f30c93&idx=1&mid=2247484679&scene=21&sn=e0d4a79995bd669a36a900fcfd7d0249#wechat_redirect
[Link 4]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1ca77ccb643619ebd812997ebca319c03cec606ed3510bbdf86c3ada7790c4d4abe22282a&idx=1&mid=2247484603&scene=21&sn=5a0ebe2a691ee77c2a2489ef320afb26#wechat_redirect
[Java]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1cb36ccb6422021be4e85e8152d660403e2a2359f937634701bf27342da75e4ac81558b0d&idx=1&mid=2247484922&scene=21&sn=e30aef5645e76c09b56b110e1d5d2633#wechat_redirect
[Redis]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d5b1ccb65ca7e6c87ef32d3065111a9181c398e6ad39b66cf4f07f03167998a8b07f3bd1&idx=1&mid=2247490429&scene=21&sn=3c6e19f168166593d5d050bfe6b24410#wechat_redirect
[Java 1]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d5d5ccb65cc3909a0d110a38ced89e9f8ebaec4f1d24088ed23c287b7032dba52f806542&idx=1&mid=2247490329&scene=21&sn=36f8cab59918bf1c8d0499ef6c7da13c#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d591ccb65c874368c7940d76355d95185fb379cc3bc5f97fdc505b96ab1a03e68b59a94a&idx=1&mid=2247490397&scene=21&sn=9688c6f29545ea6c11325cbd6ab01c2a#wechat_redirect
[60]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d557ccb65c41ec5d3b7dedd6c7a22949ddcb5de1406de482c3b702a1a4768c66b730b219&idx=1&mid=2247490459&scene=21&sn=66bc23ae41a8abcb9a6f00be754b2e47#wechat_redirect
[21 _HashMap]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d429ccb65d3fc4be6ab008e4318d3beeccb1394801c72e33cbb9fd162868dce2b9b0c0f2&idx=1&mid=2247490277&scene=21&sn=63d44db7ae6930f25478119f423227d4#wechat_redirect
[float]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d5cdccb65cdb97329d4ab51a9362c0515d6fe70c3def3dfa370cc2439fef10f9c2a87c51&idx=1&mid=2247490305&scene=21&sn=5649957d74d035a0919293b92a5659f6#wechat_redirect
[Date_Java8]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d61eccb65f0864848b37346e5974185df98744a6509b8330796898926ead638ebf5ef5c9&idx=1&mid=2247489746&scene=21&sn=50c98d26b5f2bf0d3d5be902468b54dc#wechat_redirect
[10]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d748ccb65e5e8bfe2334dac9c4a1678fa77a4b1c6bb230fb4442682c36120cfb8d8941ae&idx=1&mid=2247489924&scene=21&sn=40b4b841430ae75879b25545291dbf0a#wechat_redirect
[format_png 9]: /images/20221124/6d011a8330474998af1ecbe191127ee1.png
[format_png 10]: /images/20221124/697bd400afbd4d4b8969ae867633cc2c.png
[format_png 11]: /images/20221124/d3b2c7f62db14d5ba5de910b9753f181.png
[format_png 12]: /images/20221124/b38050ea6a26430883177f88cdbb86bc.png
[format_png 13]: /images/20221124/b3c85e384b8541b198e76cf41e45eea7.png
[format_png 14]: /images/20221124/40b1a81a5d4e4c73a078b0263f264912.png