nothing

      1，错误情况一定要处理，要么写错误日志，要么返回给前台，一定要记录关键信息以便定位问题
      2，正常操作如果要记流水的话，与错误日志分开，两者用途不同
      3，在效率与模块清晰性之间，优先考虑模块清晰性，简单的结构更容易优化
      4，通讯协议尽量简洁，简洁意味着高效，同时必须考虑扩展性，可以设计变长头部/可选头，版本等，
      5，在不牺牲简洁性和效率的情况下，尽量考虑用配置驱动行为
      6，尽量支持可探查性，通过外部工具能实时了解服务器内部状态，可考虑支持修改内部状态
      7，系统分层不宜过少，过少内聚不够，结构比较散，也容易潜藏bug，也不宜过多，过多效率下降，出错可能性也会增加
      8，内存尽量预分配，可简化逻辑，减少bug，并提高效率
      9，查询+操作的方式尽量换成操作+返回错误的方式，如果大部分情况下操作会成功的话
      10，可适当考虑协议转换层，将通讯数据包转换成结构体或反之，优点是功能分层，将通讯和逻辑处理的数据表示分离，结构更清晰
              缺点是多了一层，可能会多一些代码（通讯数据包与结构体互转），而且部分字段的转换中某些情况下可能不需要

    默认情况下，函数的参数类型如果是数组或函数会decay为指向数组元素类型的指针或指向函数的指针，但如果形参是数组或函数的引用类型，则实参的类型不会发生decay。

FUN是函数类型，不能定义此类型的数组（另外两种是void和引用），但PFUN是指针类型