20210531接下来深化解决两个逻辑思维上的bug

1.think fail not success：

~~其实也可以有run，init这些，但是无论是哪一层都需要遵循的原则是：重点来了：~~  
~~就目前的整体逻辑而言，除了各个receiver的数据可以发送给前端ui~~
~~只有某个client自身的“连接成功(而且是哪个接到欢迎信息后的)、主动断开”这两个类型需要让前端知道，其他的都是只记录日志即可~~

~~同时从这里延申思考一下，其实对于初始化的问题，你只需要保证程序完成初始化前不会被消息卡住即可~~
~~节点中虽然也有RUN，但是他们都是只有当client连接成功后才会进行阻塞与传输~~

~~我可以用run和consturct来明确哪些是属于main层初始化的哪些是非main层初始化的，因此run与construct不可乱用~~
~~不不不，run和construct到是都行，应该用init来明确哪些属于main层初始化的内容~~
~~而又会发现还是有诸如evnetbox.Analysing()这样的方法需要执行，你需要确保这些昂发内部不能由管道/事件与消息传递~~

**似乎越简单的方法越好，也就是将rn层以上可能会引起此问题的events全部进行诸如go Events<-event,这样的操作**

**似乎从server层开始，所有的发送events逻辑都需要go一下，这样搞其实逻辑上还是挺清晰的**
**或者说那些只要记录日志的不用go，而那些需要发送给前端的则是必须的**
另一方面，必须确保eventbox与errorbox尽可能早的实现初始化，并调通相关管道
之前之所以卡管道，其实只是因为events管道没有调通
**是tcpmanual的TCPMANUAL_PR_RUNSUCCESS和TCPMANUAL_PS_RUNSUCCESS这两个事件被卡了，因为他们发送不到任何一个flutterUI客户端**
于是现在只讨论针对这两个信号的解决方案：

可以go他们，**也可以只让他们记录日志，换句话说其实就是让server层只有TCPMANUAL_QUIT需要发送至前端**或者两者都实施  
罗列下server层的信号：

TCPMANUAL_INITFAIL =iota//Event
TCPMANUAL_RUN//Event
TCPMANUAL_ERRORINLOOP//Error
TCPMANUAL_PANICH//Error
TCPMANUAL_LISTENER_CLOSEFAIL//Error
TCPMANUAL_LISTENER_CLOSESUCCESS//Event
TCPMANUAL_CLIENT_ACCEPTED//Event
TCPMANUAL_CLIENT_ALIVE//Event
TCPMANUAL_CLIENT_UNDEFINED//Error
TCPMANUAL_CLIENT_DROPSUCCESS//Event
TCPMANUAL_CLIENT_DROPFAIL//Error
TCPMANUAL_PS_CHECKERROR//Error
TCPMANUAL_PS_ADDPUBFAIL//Error
TCPMANUAL_PS_INITFAIL//Error
TCPMANUAL_PS_RUN//Event
TCPMANUAL_PS_STOPSUCCESS//Event
TCPMANUAL_PR_ADDPROCFAIL
TCPMANUAL_PR_STOPSUCCESS
TCPMANUAL_PR_INITFAIL
TCPMANUAL_PR_RUN
TCPMANUAL_PR_DOPROCERROR
TCPMANUAL_PR_CHECKERROR
TCPMANUAL_PROACTIVE_DESTRUCT//Event
TCPMANUAL_PROACTIVE_DESTRUCTERROR//Error

可以看到，其实还是挺多的，每个都go的话似乎是不太优雅
感觉无论是现在还是将来，无论设计哪个程序，有必要去明确一种不需要独立线程即可实现的事件传递机制  
说白了，还是要完善Errors与Events的日志录入机制，确保日志录入模块初始化成功后绝对不会发生因录入日志的管道阻塞问题，而绝不是**用go的方式逃避问题**  

目前所想出的解决方案事，server层(tcpmanual)所产生的event与error不在需要汇报给某个tcpflutter.sender,
或者说tcpflutter.sender需要去处理的事件其实是少的可怜的，其不需要sender去处理的一并只进行log即可

2.子线程正确的wg使用方式