因为在luban出来之前我还真是你这样做的，后来有了luban以后，我立即投奔luban因为足够好用
对啊，相对楼主的插件导表，我的低效处理方式的确更优秀，请你反驳，不要拿luban自由代入！
我一开始提出luban，只是luban正好解决了你和楼主讨论的问题。
后来你一直在说你这套方案的优势，我自然也给出luban的相应解决方案，没问题吧。
我拿luban怼你啥了？
不反驳了，健身去勒 
你应该拿luban去和楼主讨论他的插件具有哪些痛点，让他去改进，我提出痛点，并能在我现有实现下解决。
失之偏颇的讨论，就是“怼”，知道为什么我还在坚持跟你讨论了吧，楼主那低素质的，我都懒得理他了。
没事没事，支持luban谢谢喵，希望这个讨论不要让你产生对luban的厌恶，这真的是一个好用到夸张的工具。 
看完文档后,我觉得可以用一句话来总结这个工具
每个使用平台或者使用者都可以从这个工具中方便定制属于自己的个性需求.
因为抽象,所以方便个性化定制.
真是个好东西… 我的需求可以方便地满足.
1赞
刚去看了下luban，功能挺多，不过某些情况还是不合适，比如 Hero表有个技能数据，“1,1408101;41,1408102;81,1408103;121,1408104”，这个结构是{英雄星级：技能ID}，其中技能ID可以配置多个，需要根据策划提供的方案进行技能合并，而且技能合并还比较复杂（需要按技能权重排序确定首技能，然后将后续技能的属性和Buff按一定规则合并到首技能），此时需要把这个字段映射为更复杂的自定义复合对象 {星级： {技能类型： 合并后的技能}}，而且读取数据时需要快速定位数据，后端java可以引入Guava TreeRangeMap，TS却只能循环遍历，这种情况luban是好像无法处理，请问，你能给个建议吗？
我不会配置这么复杂的表，按照我之前说的，这属于post-pipeline的内容，在c#里可以使用分部类，在ts里可以做一个helper函数。
如果你偏要
1.你可以考虑看一下luban的定制开发方案，直接配置这么复杂的结构是不可能的。
2.让策划写一套公式，策划远比我们想象的会用excel。
luban 确实是更好的方案。你的需求，在luban 的解决方案里，可以通过定制 DPP 管线实现。
如果要用地编，一般首选 Tiled Map。除了文档和功能齐全之外，最重要的是，它是标准化了的软件。luban 就是配置表的标准化工具。为什么有那么多标准化组织，标准化的好处就在于降低成本，减少内耗。
策划一旦掌握。以后他做别的什么 Unity Godot 或者 App 项目，都可以用这套配置工具，相互之间都有公共的知识背景。
你让大家学习 luban，肯定好过学习你的配置体系。
文档不用你写，技能不用你教，你省了时间。他们获得了更通用的技能。双赢。
有我这种需求案例推荐吗？看文档，DPP就是一笔带过。
+1
你这种应该业内很多在用，我们 java 后端就是打成.bin，然后预处理这块真的很有必要。我前端目前是 json 有空也改造 csv
引用这个学到了
我没做硬性要求数据是否存在，因为之前我在工作中使用时几乎每个空数据都要进行判空处理很不方便
所以数据不存在我会在导出时根据数据类型给一个默认值，比如"", 0, false, []，只要有效值避免使用这些默认值即可
我们会把定义导出来，类似于next_task: string?等，方便ts检查，在实际使用过程中，需要判空的概率不是很大，由于我们有做约束检查，比如使用另一张表的id等，代码中直接索引不需要判断
那你一定是用了严格模式
，如果不用严格模式的项目使用到了undefined的进行运算就报错了，老项目也没法改
必须上严格模式 
，自从用了ts，记忆力直线下降。。。。