-
空指针的使用
调用了一些内部会销毁指针的函数（背包函数居多，比如合并物品）后，下面的日志输出里面再次用到了该指针Tips:普通的空指针判断起来都很容易，最怕的就是这一些操作指针的接口，在调用时很有必要去接口内部看下是否存在对指针的操作。
-
野指针的使用
家族驻地存在一个自动销毁的机制。但是之前由于销毁场景时仅仅销毁了scene指针，却没有销毁当前scene下的所有Npc。导致此时那些npc身上存的scene指针都成了野指针，这些npc被人为调用todie销毁时，访问了其scene这个野指针导致宕机。Tips:野指针的问题一般都比较不好直接定位，比较难查。在编码时需要注意，涉及到一个指针销毁时，考虑下该指针是否存在一些别的被引用地方，如果有，需要对那些地方做下置nullptr处理；此外尽量不要直接保存一个指针，比如需要管理npc的话，尽可能保存期npc的唯一id，而不是指针，再需要访问时，通过唯一id从管理器获取指针再访问，可以减少这个野指针出现的情况。
-
循环的内部释放了容器
每日目标功能曾经出过一个bug，玩家开着界面隔天，领取前一日达成的目标时，服务器宕机。基本的原因在于，这个跨天领取时，会遍历更新一个容器的状态，而遍历过程中调用的一个函数触发了每日目标的跨天重置机制。这个重置机制会释放掉当前这个遍历的这个容器，从而导致了宕机。Tips:在循环遍历操作一个容器时，其内部的调用接口尽可能避免出现操作容器本身的地方，两者的逻辑尽可能解耦掉。
-
递归死循环
项目里面有个函数getTopMaster()。是获取一个npc的最上层主人。这是个循环递归获取的函数，但是由于没有对递归次数做限制，对于一些助战Npc，策划通过脚本配置召唤出来，由于配置不当和程序部分代码不健壮，出现过该函数在无限递归循环。Tips:所有涉及循环和递归的接口，都需要评估下风险，诸如这一类的无法直接预见性循环次数的，都需要人为加一个防错循环上限值。
-
变长消息拷贝溢出
项目里曾出现过这样的情况，Function宕机后重新拉起，但是却引起了Session的宕机。排查后发现是Function起来后，Session会同步当前所有的玩家基本数据到Function，宕机宕在了这个同步玩家数据的消息拷贝这里。由于考虑到玩家人数可能会很多，所以在循环拷贝玩家数据到变长消息结构的时候，程序上是做了一个限制的，限制的条件是一次性同步的最大玩家人数。问题就出在这个人数上面，由于玩家的基本数据结构在项目后期是会变大的，导致之前限定的单次同步人数最大值*一个玩家的基本数据后的总大小大于了我们设定的一次消息发送缓存区的大小，从而导致了stack-overflow。Tips:这个同步策略需要修改为判定当前拷贝进去的这个变长消息的大小是否合法，而不是判定同步的玩家人数。因为导致栈溢出的是这个消息结构申请的内存空间不够，这个空间大小不仅取决于个数还取决于单个数据结构的当前实际大小。
