抛砖引玉

配置表检查工具在游戏产业还是十分需要的，检查节奏是理论每次发版本或者配置表有变更时都要做检查，配置表填错规则，不光是不生效，影响有：

普遍为客户端崩溃，严重可服务器宕机和对应节点服务异常错误影响个别功能使用。
配置表检查在互联网来说这个名词还是比较陌生的，不是那种配置中心 Yaml 文件的那种。
略做解释，一个游戏展开后，配置表可能有几十张甚至过百张，一个成熟的作品，数据整量过百 M。

游戏配置表大多数是 csv，然后可以支持给客户端/服务端读（有些也会放美术配置，美术的主要还是给客户端读的），读起来分为转换 lua，载入内存，取不同 row 转换一个结构体去读，结构体可以理解成 go 语言的 struct。

足够灵活和强大，配置表主要维护者是策划（等同互联网的产品，比他们更低的游戏产业策划比他们苦多了），我见过一家公司的配置表已经包含了不止是 OOP 还包含了时序，AOP，事件驱动，序列化数据结构 Pb 支持部分区域（注意不是 row 列那么简单），支持 SQL 语句和协议 ID，讲道理，真是完全不出错，起码是使用同一套的熟练工。
然而不同公司又是不一样的，这样也导致配置表出错概率不低。

不知道这里是否有其他方案可以抛出来聊聊。

静态扫描

配置表检查工具很多公司程会自己做，如果是开发自己做得载入后检查，只能检查登录载入数据，阵容，道具，货币，活动等，一些需要运行时的，只能通过标准规则去测试，也就是基于规则的静态扫描。

• row 某些列数据包含几个特殊字符，特殊字符分别含义，检查这些列特殊字符没有写错。
  
• 日期格式（yyyy/mm/dd 和 yyyy-mm-dd），不同策划那边没统一 format，打开后再保存就翻车。
  诸如此类，都是可以通过不停添加规则，然后开多线程让规则有顺序关系的套规则去检查，笨是笨了点，但检查效率也不慢，静态检查本身还是以表做为参照物。

需要动态原因

如果设置到登陆后绑定了玩家数据（加载了公会信息，背包数据，活动信息，战斗阵容，组队状态等等），不同玩家里面信息甚至检查维度都是不一样的，因为玩家信息不同引发的动态。

• 玩家组队状态异常的去访问了其他地图，导致地图抛错。
  
• 玩家身上唯一道具在其他玩家身上因为掉落拾取后，导致背包一直抛错。
  

这些绑定了玩家数据后的，是无法用静态规则的方式扫描出来的。

实现动态检查的方式，还是先得建立检查规则，再根据检查规则进行排序，和静态不同的是，通过接口测试和一些测试服数据库字段修改去模拟检查规则，同时监听服务器对应执行单位的日志是否有抛错。

所以这里包含了多个工具混合：接口协议支持，监听服务端执行单位的日志，数据库自动修改字段，mock 规则。

不知道这里是否有其他方案可以抛出来聊聊。