你看我这个没？除了手鲁的这个Bean，其中引用了技能表和自定义多语言表，都是Ref，并不要拿ID去找哦，只是运行期加载表，如果不做验证会置null而已。
我也没说luban不好吧，就说了在程序与策划明确类型的情况下，自动化没那么重要。
再就是，我在和楼主讨论我提出的问题，是你主动引入luban的话题，都有不完美的地方，你为啥拿luban怼我呢？
https://luban.doc.code-philosophy.com/docs/manual/architecture
我建议你看看luban的设计哲学，它提到的所谓的那些痛点问题，你能不能给出相应的解决方案。
之前只是看到你讨论的问题，luban正好都有完美的解决方案。并不是拿luban怼你，现在你反而在用一些低效的工作流来不停的证明你的正确性。
如果我说低效伤害到了你，我很抱歉。
你可以夸赞luban的一切，但我不知道在没有luban的时候，你们是怎么处理的？难道luban出来后你才入行？
在不加入luban的话题这个前提下，我有贬低过任何一方？我只是举例楼主那个插件的某些情形无法处理的痛点，你把luban推出来是几个意思？
因为在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
引用这个学到了
