更新README

Author: Cai-ki

README.md

@@ -13,83 +13,60 @@
 
 1. 客户端初始化与发送逻辑顺序问题
 
-    现象 ：编写测试代码时发现客户端在未完成初始化时就执行发送逻辑，导致空指针异常。
+    现象 ：测试时客户端未完成初始化即执行发送逻辑，引发空指针异常。
 
-    原因分析 ：
+    问题本质 ：协程调度顺序不确定导致：
 
-    代码中多处使用协程并发执行，由于协程调度顺序的不确定性，导致以下执行顺序错误：
+    - 连接未初始化完成
+    - 发送逻辑提前执行
 
-    - 客户端连接尚未完成初始化
+    解决方案 ：
 
-    - 需要连接对象的发送逻辑已提前执行
+    - 引入 ready 管道同步协程
+    - 调整关键协程启动顺序
+    - 非关键路径保留并发
 
-    解决方案 ：
+    经验总结：
 
-    - 引入ready管道作为协程同步信号
-    
-    - 调整关键节点的协程启动顺序
-    
-    - 保留必要的并发逻辑（非关键路径保持并发执行）
+    - 执行并发逻辑需确保依赖实例初始化完整
 
 2. 高并发场景下的服务端稳定性问题
 
-    现象 ：压力测试时出现端口耗尽导致客户端异常断开，进而引发服务端崩溃。
+    现象 ：压力测试时端口耗尽导致客户端断连，服务端崩溃。
 
     问题本质 ：
 
     - 连接异常处理机制缺陷
-    
-    - 并发协程间的资源竞争
-    
-    - 连接关闭时的任务执行完整性问题
+    - 并发协程资源竞争
+    - 任务执行完整性不足
 
     改进方案 ：
 
     - 状态管理 ：
 
-        - 新增原子变量标记连接状态
+        - 原子变量标记连接状态
 
-        - 使用sync.WaitGroup跟踪任务执行
+        - sync.WaitGroup 跟踪任务
 
     - 执行流程优化 ：
 
         ```
-        // 连接异常处理流程
-        reader检测异常 -> 设置关闭状态 -> 触发stop流程 -> 
-        wg.Wait等待已接收任务 -> workpool继续执行遗留任务 -> 
-        writer无脑发送（忽略错误） -> wg.Done -> 清理资源（关闭msg管道等）
+        reader异常 -> 设置关闭状态 -> stop流程 -> wg.Wait -> workpool处理遗留任务 -> writer尽力发送 -> wg.Done -> 清理资源
         ```
 
     - 容错设计 ：
-        - 任务提交阶段不进行连接状态检查
-    
-        - 写协程统一处理发送异常
-        
-        - 提供用户级熔断接口（通过handler提前return实现）
+        - 任务提交不检查连接状态
+        - 写协程统一处理异常
+        - 提供用户级熔断接口
 
     - 性能考量 ：
 
-        - 采用"尽力而为"策略处理异常连接的任务
-        
-        - 通过wg.Wait()保证已接收任务执行完毕
-        
-        - 优雅关闭时确保：
-
-            - reader先行退出
-            
-            - writer处理完消息队列
-            
-            - 管道关闭时无残留数据
+        - "尽力而为"处理异常任务
+        - 优雅关闭分阶段执行（停读 -> 停写 -> 清理）
 
     经验总结：
 
-    - 协程同步应优先使用简单同步原语
-    
     - 资源释放需保证执行完整性
-    
-    - 异常处理应区分系统级和业务级容错
-    
-    - 避免过度设计，当前方案在代码复杂度和功能需求间取得平衡
 
 3. 服务端异步启动后 stop 在大量并发连接下的死锁问题
 

log.md

@@ -2,83 +2,60 @@
 
 1. 客户端初始化与发送逻辑顺序问题
 
-    现象 ：编写测试代码时发现客户端在未完成初始化时就执行发送逻辑，导致空指针异常。
+    现象 ：测试时客户端未完成初始化即执行发送逻辑，引发空指针异常。
 
-    原因分析 ：
+    问题本质 ：协程调度顺序不确定导致：
 
-    代码中多处使用协程并发执行，由于协程调度顺序的不确定性，导致以下执行顺序错误：
+    - 连接未初始化完成
+    - 发送逻辑提前执行
 
-    - 客户端连接尚未完成初始化
+    解决方案 ：
 
-    - 需要连接对象的发送逻辑已提前执行
+    - 引入 ready 管道同步协程
+    - 调整关键协程启动顺序
+    - 非关键路径保留并发
 
-    解决方案 ：
+    经验总结：
 
-    - 引入ready管道作为协程同步信号
-    
-    - 调整关键节点的协程启动顺序
-    
-    - 保留必要的并发逻辑（非关键路径保持并发执行）
+    - 执行并发逻辑需确保依赖实例初始化完整
 
 2. 高并发场景下的服务端稳定性问题
 
-    现象 ：压力测试时出现端口耗尽导致客户端异常断开，进而引发服务端崩溃。
+    现象 ：压力测试时端口耗尽导致客户端断连，服务端崩溃。
 
     问题本质 ：
 
     - 连接异常处理机制缺陷
-    
-    - 并发协程间的资源竞争
-    
-    - 连接关闭时的任务执行完整性问题
+    - 并发协程资源竞争
+    - 任务执行完整性不足
 
     改进方案 ：
 
     - 状态管理 ：
 
-        - 新增原子变量标记连接状态
+        - 原子变量标记连接状态
 
-        - 使用sync.WaitGroup跟踪任务执行
+        - sync.WaitGroup 跟踪任务
 
     - 执行流程优化 ：
 
         ```
-        // 连接异常处理流程
-        reader检测异常 -> 设置关闭状态 -> 触发stop流程 -> 
-        wg.Wait等待已接收任务 -> workpool继续执行遗留任务 -> 
-        writer无脑发送（忽略错误） -> wg.Done -> 清理资源（关闭msg管道等）
+        reader异常 -> 设置关闭状态 -> stop流程 -> wg.Wait -> workpool处理遗留任务 -> writer尽力发送 -> wg.Done -> 清理资源
         ```
 
     - 容错设计 ：
-        - 任务提交阶段不进行连接状态检查
-    
-        - 写协程统一处理发送异常
-        
-        - 提供用户级熔断接口（通过handler提前return实现）
+        - 任务提交不检查连接状态
+        - 写协程统一处理异常
+        - 提供用户级熔断接口
 
     - 性能考量 ：
 
-        - 采用"尽力而为"策略处理异常连接的任务
-        
-        - 通过wg.Wait()保证已接收任务执行完毕
-        
-        - 优雅关闭时确保：
-
-            - reader先行退出
-            
-            - writer处理完消息队列
-            
-            - 管道关闭时无残留数据
+        - "尽力而为"处理异常任务
+        - 优雅关闭分阶段执行（停读 -> 停写 -> 清理）
 
     经验总结：
 
-    - 协程同步应优先使用简单同步原语
-    
     - 资源释放需保证执行完整性
-    
-    - 异常处理应区分系统级和业务级容错
-    
-    - 避免过度设计，当前方案在代码复杂度和功能需求间取得平衡
 
 3. 服务端异步启动后 stop 在大量并发连接下的死锁问题