用cocoe这么多年。不管团队多少人，从来没碰到prefab冲突的。
我规定谁做的prefab 随跟进。代码和prefab绝对分开。不能有相互影响
界面 ： prefab可以用vue类似绑定值/状态，因为公用的所以做好了空置判断，
代码 ： 代码绑定组件。也必须做好控件不存在的判断!
不管怎么改界面。也不管怎么改代码都相互不影响。
我是菜鸟。见识可能与大神有差距，在ui上从来没考虑过性能问题，可能我做的项目太垃圾。没碰到过性能问题
要是编辑器没有bug不会丢失绑定的组建A还是很香的。如果丢失了绑定节点，不是自己写的界面要找回这个节点还得看整个逻辑还是很烦躁的。所以建议复杂界面还是代码取节点选方案B，简单界面编辑器拖放节点选方案A
你是怎么做到 vfor vif 的？能介绍吗？
感觉这个方式很有趣，但看不懂，能说具体点吗？
我觉得编辑器。应该加个node绑定了自定义脚本标识，
之前好像有个大神有提过这种建议。就是给绑定脚本的node改个颜色。或者加个小图标
我的vfor 和vif 用的就是Function,也没有全部按照vue的来。太复杂了，就简单用了Proxy解析一层
在编辑器做标识，这个建议很不错，感觉很需要
看来是时候出一本《Effective Cocos Creator》了，把最佳实践都写进去，如果有这样的书我肯定会买！
最佳实践。我也买。
用B是因为代码分离吧。
美术拼界面。程序员接手。
如果像A。那么如果修改了UI的话。美术和程序员耦合了。
一开始用的A方案，后面统一用B方案，维护起来比较方便
两种都尝试过，感觉接近UI的话偏A会好一点，B会更绕。
举个栗子，假设有个功能模块由左边的区域X和右边的区域Y组成。
正常设计应该是Ctrl+X+Y，Ctrl持有X和Y的引用。X和Y对外提供接口给Ctrl，对内直接操作UI节点。Ctrl主要是业务逻辑，调用X或者Y提供的接口，不会直接操作单个UI节点。
到这里A流派和B流派都没啥不同，除了A是组件流，B是类流。
实例生命周期：A组件跟随节点，B类自行控制
初始化：A随节点一起，B显式调用init
定时器schedule与unschedule：定时器是Component提供的接口，A是组件直接可用，B需要想办法先获取组件。另外， 定时器的取消如果是组件也会方便不少。
编辑器拖还是代码绑节点这里不是重点
我一直很好奇上面的大佬，ccc的“大”项目是什么样子。。。没经手过，想象不出来 
我比较喜欢自己控制生命周期，你说的schedule（Laya里叫Timer） 这个感觉不应该放在Component里，因为数据层或者逻辑层也需要timer事件。
个人感觉区别就是一个是内置(引擎帮你处理好了)，一个是自定义控制(自己控制生命周期等)，说句不好听的，换个引擎，B方案更合适
你去cocos的官网去看看那些摆在首页的游戏不就知道了嘛。
看过，应该是官方放出来的比较少吧
嗯， 这里说的前提是接近UI的处理，好处就是定时器跟随组件一起销毁。如果是离UI比较远的，那自然是没必要强行跟Component绑在一起，setTimeout也可以，但是需要格外注意生命周期，好多bug就是忘记取消定时器或者设置了多个定时器导致的。
传奇应该是吧？
传奇应该是cocos-lua写的。 这么看来，creator真的很尴尬啊。一直被lua吊着打
