如果我是主程或者架构，我愿意。。。。但是。。。我拿来总觉得没什么用
B不就回到了以前2DX+CocosStudio的开发方式
是的呀。但是经过我初步的推断。现在中国游戏公司里至少还有 50%的项目组还在用 cocos-lua 来开发游戏。
你这个节点获取是遍历所有子节点吗？这样可能会有性能问题
前端界面真心没有什么性能好担心的。除了做道具列表那种list注意下。其他的随便折腾
是所有频繁加载的预制体，用这种方式都会存在性能问题
你的思想很危险啊。前端到处是性能瓶颈啊。
我以前也是这样，只是眼看小日子越来越有判头了就换工作了。。。换工作后再这样就尴尬了，性能上各种比不过以前的玩意
全靠A很难做代码审查，会把人逼死
添加节点路径也一样有问题，如果 A 是 B 的父节点，同时引用两个节点，获取 B 时应该直接用 A getChild，如果全是路径就会遍历两次造成不必要的消耗，我现在是用一个单独的 class 文件做的获取，获取完时再遍历是否为空，有就打印error
非也，现在大部分程序应该都是用的动态加载预制体吧，如果做好代码关联，实际并不会出现找不到加载的组件 class，new 一个class 和 调用 class 内的静态创建函数，难道有什么可读性的区别吗？再或者只要有这个 class 的引用，比如 ui_manage.open(ClassA)，那么也可以跳转到对应类，如果是动态加载，只要预制体名和类名一致，也可以找到对应类型
缺点就是有可能出现的引用丢失，还有某些独立工作的组件不好溯源需要看节点树
引用丢失除非必要就不要去拖各种属性，我一般都是动态加载的，独立组件那就没办法了，只能自己做好注释，如果是 B 方案添加完依赖的独立组件还需要代码配置属性，而 A 则可以在编辑器直接配置
不，我司一个项目大部分直接把预制体拖拽进编辑器，直接获取。按钮点击也是直接拖拽脚本进去的，根本找不到点击节点，节点引用到处飞，按钮点击用什么什么脚本，然后脚本上挂载了什么预制体，加载到什么地方，全部得看编辑器，更恐怖的是有好几层。这还是流水过亿的项目。你可以想想有多乱。如果不是真的没人看得懂了，他们还不愿意重构，屎山越叠越高，
而如果审计看这样的东西。是直接不合格的
重复遍历的问题，可以维护一个map，并通过反向路径查找解决。比如
A节点路径：root/$A
B节点路径：root/$A/other/$B
先查到A，则 map.set(“root/$A”, A)
再查B，先按路径反向查找，先查 root/$A/other 这部分，通过 map.get(“root/$A/other”) 结果为空时继续查 root/$A，就可以拿到 A ，再按路径正向查即可
先查B的话，还是先按路径反向查找，在map中一直反向查到 map.get(“root”) 为空，开始正向查找，root/$A 符合节点规则，添加到 map，继续向后查，直到 root/$A/other/$B
再查A，直接 map.get(“root/$A”) 就有了
不建议滥用…… 规范起来，首先是代码层面，哪些组件可以互相依赖？其次是依赖的对象需要有选择，可以通过各种方式获取和查找组件，不一定非得全部直接引用。
我来的时候人都看傻了，这也能跑？这也能赚钱？
是可以这样解决，我后面也想改成装饰器，不过我喜欢把节点引用集中起来，比如this.nodes.xxx
赚不赚钱和代码乱不乱没有关系，那个啥全是if的游戏不也能赚钱，忘记名字了