工作这么多年了，每个参与的项目，都是用excel来配表，然后用一些脚本转换成json或lua，再去读取。这种方式实在太low了，有许多的问题
1读取配置性能消耗，从json或lua之类的文件读取配置，再解析转换成当前项目的代码的数据结构，需要消耗一定的时间
2需要额外写代码去组装配置，最常见的就是将一个数组型的配置数据组装成一个以id为键值的字典，这种类似的逻辑我都快写吐了。还有些特别的配置，需要用两个键值组成作为键值等等之类的需求。
3字符串解析。很多配置，最常见的就是奖励，通常会写成一个用某某特定字符分割的数组，为了这种设置，需要额外的做一些字符串分割解析操作。如果配置设计的不好，会需要大量的额外代码去解析。
可以吐槽的地方实在太多了，就没有人做过一个专门用于项目开发的配置工具吗
可以转成二进制格式的yaml文件，可以参考U引擎的官方实现，折中的方式是转成bson文件
如果读JsonAsset太费时间，那直接导出ts文件，编进代码里试试。
这种方式并不low，所有都是需求出发的结果，策划拿不到代码工程，最直观的配置肯定是 Excel,因为标准统一，学习成本最低。
所以 Excel 所扮演的角色叫“标准化工具”，有标准，意味着可以知识通用、复用，成本才低，效率才高。
Excel数据要通过工具转为其他数据，这所有其他数据，也都是在对象环境下的标准化格式。
如果是个人项目，那个随便哪个都行，直接转出ts代码都行。但是如果是项目组的，得考虑其他成员能掌握的。不仅仅是因为Excel是一个标准化，还以为Excel维护成本很低
策划肯定是要用excel配表的，因为通用。但是你可以考虑生成代码去处理json生成对应的类型数据。类型的话，就让策划配表的时候也一起配下。比如一张奖励表
id reward
number [number,number][]
生成一个类，
tblReward{
_data:any;
id:number;
reward:[number,number][];
constructor(data:any){
//这里做初始化，根据字段和类型生成模板代码
}
}
可以明确的重复操作都没必要留到写业务逻辑的时候处理吧，而且完全可以只做少量工作后全用程序生成。
还有，配置表的表头不应该程序设计么?
1赞
配置是给策划用的，Excel是策划用起来最习惯，沟通成本小也最不容易出错的。就这样，少折腾一下吧 
1赞
可以专门做一个游戏管理后台系统。配置保存到mongodb数据库库中，远程读取，这样还能动态更改配置。不过这个管理系统开发成本也不小。不过可以一劳永逸。