🤔文章中的遇到的问题 ✏️ 问题 1、在代码仓库 Generic 没有这个枚举值 ReceiveResultT，不知道是不是其他分支的代码。 “ReceiveResultT # 我们会接收的 Response（Result）类型” ✏️ 问题 2、message_handler 笔误？应该为 logging_callback？ 都会统一委托给用户在构造时提供的 message_handler，以便在上层进行监控、界面更新或其他自定义处理。 📚 思考题 📒 1、如果要在 BaseSession 之外引入一个新的消息优先级机制（比如“紧急通知”要比普通通知先被处理），你会在哪里、如何修改或扩展流程？提示：你可以试着画出在 _receive_loop 中插入优先级判断的思路。 创建两个内存队列，分别为高、低优先级队列，在 _receive_loop 判断消息的优先级，如果是高优先级的消息则存放到高优先级队列，低优先级的同理。然后处理消息时，先判断高优先级队列中是否有消息，有则先处理，若高优先级队列没有消息则处理低优先级的队列中消息。 问题：因低优先级消息可能长时间未被处理，会导致消息堆积甚至占满队列。解决方案：可以做一个机制，当低优先级一段时间未处理，则移到高优先级队列。 问题：高优先级队列占满和堆积。解决方案：在入队列之前做一些限流，或进行服务扩容。 📒 2、考虑一种场景：你希望在 ClientSession 中统计所有发出的请求和收到的响应的往返时延（RTT），并在超过阈值时发出告警通知。哪些地方最合适插入埋点？ 方案 1：在 BaseSession 的 send_request 方法中加上埋点，统计往返时延。（推荐） 方案 2：在 ClientSession 的 所有 self.send_request(xx) 方法的前后加上埋点，统计往返时延。