共计 1222 个字符，预计需要花费 4 分钟才能阅读完成。
- 空指针的应用
调用了一些外部会销毁指针的函数（背包函数居多，比方合并物品）后，上面的日志输入外面再次用到了该指针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: 这个同步策略须要批改为断定以后拷贝进去的这个变长音讯的大小是否非法，而不是断定同步的玩家人数。因为导致栈溢出的是这个音讯构造申请的内存空间不够，这个空间大小不仅取决于个数还取决于单个数据结构的以后理论大小。
正文完
