最近出现一个第一次见到的奇怪现象，属性战斗力计算流程是我开发的，后来另一个同学的某个业务需要算这个数值，然后发现某几个对象算出来的值不对，该同学看了下代码，看了下原始配表，都没问题，后来找到我，让我帮忙...
因为是部分正确，部分不对，即不对的部分的某一步骤出现问题导致期望的数值不符合，值为NaN而非某一个具体的数值；当某个数组中都为number时[number, number, ..., number]，算出来的值是没问题的，如果某一项为空，即取不到则算出来是NaN，所以可以从这里下手...
因为参与属性计算的流程比较复杂，但最终是算出各属性值，所以可以从某个属性字段为空来排查；既然是部分有问题，且参与计算的对象数据都没问题，可以从原始配表数据排查...
从转过原始表后的配表数据看，是少了某一项参与计算的属性值，然后我本地导一下原始表，发现有异常，但此异常被后面的日志给滚动掉，且不大容易去发现问题，所以问题就出现在这，表格是excel且该列的类型是int....
后来检查原始表，直观上看，策划配置的数值是没问题的，非常正确，但导表时，int这列部分正确，部分不对，异常中提示是数据类型不对，为什么呢？比如表中填的是30，导出的结果有30，有30.00000000001或者29.99999999998这样的数值，故类型不匹配则报错....
再次检查原始配表，各项数据都没问题，然后检查导表工具的源码，也没问题，因为导表是用go写的，且对于excel中某个固定行的某个列取类型值是int，在处理该列数据时，会使用int32判断和处理，因为配表中基本不会出现超过int32的数值...
工具中并没有兼容int或者int64，如果配置成前者就不会报错，但最终值导成的配表中是浮点数，出现游戏数值错误，不符合预期，所以这里需要从根本原因解决...
这个问题蛮奇怪的，因为是最近才出现，且工具源码没动过，且对于同样的数值，比如30，为何最终会出现非预期值？通过手动修改有问题的单元格数值，比如原来为30，手动输入30则导出的数据是正确的，不禁开始思考...
因为配表的表头是程序设计的，但数值是策划填的，程序很少会修改数值，且这个奇怪的现象最近才出现，且都跟同一个策划同学修改有关，所以就开始询问对方是如何填数值的...
具体怎么填的就不再细说，这里只是分享下如何排查这种奇奇怪怪的问题，在开发中要注意一些小异常，及时排除，不然可能很难排查。
网友评论