有个问题，为啥非要争个高低，A和B各有优势，
那就把A和B的优点和缺点整合起来，做一个C:
A主要的缺点还是集中在阅读性，特别是繁杂的嵌套，看这种代码能让人自闭，那么就避免这么操作
B的缺点也很明显，不够直观，用代码绑定节点耗性能， 那就做一个通用的X组件，
讲一下这个X组件的作用：
1、X组件只有一个属性，nodelist， 专门放节点的，不定长
2、写个扩展，专门根据上面的nodelist数据导出一个B方法需要的数据类（不继承cc.Component）
3、X组件和数据类互相持有，数据类的生命周期追随X组件，也就是X组件onload的时候创建一个数据类实例
4、（最重要的）所有预制体，场景，都不允许挂载除了X组件外的自定义组件，也就是只能挂在X组件
5、数据类外放public，X组件不外放private，主要是避免出现外部修改组件内部节点的代码
还有说到复用，我觉得比较经常复用的，还是各种item，这类的逻辑复用还是有必要的
a方案 unity 和 cocos我太爱了
b方案 让我写laya和egret非常痛苦我再也不想回去了
我现在就在写所谓的ccc大项目已经上线日本一年了 mmrpg卡牌游戏 
确实，我也就是这么一说，表达一下而已
既然各有所爱，那么就融合吧，我自己写的一套模块架构可以 纯prefab + 脚本开发，也可以预制体挂脚本开发
个人认为用A方案加上合理的目录规划，统一规范的 prefab和node的命名方式，细化功能到独立到具体prefab 就不会出现重度项目难以维护的情况，主要看架构设计，既然用cocos编辑器来开发游戏，就要相信编辑器的能力，人家是专业的 没必要非得跟编辑器强行解耦，因为你处理的节点还是叫node,而非GameObject
换引擎这个因素加入到项目开发里我觉得完全是因为想得太多，2D游戏还有比creator做得好的吗？3D的话你换成Unity也跑不起来
对我来说B方案相比于A方案，就是绕着圈的使用creator提供给你的功能，不走直线，看起来貌似脚本和prefab解耦了，实际上你的脚本也许只认特定的prefab
总结来说：A方案看起来简单，代码写得少了，傻瓜似的拖拽，体现不出自己的能力，
B方案需要多写一些代码，看起来牛逼一些吧，应该是这样
直接使用active=true 看起来很low，体现不出框架的复杂度 
啥游戏啊 观摩观摩
哈哈、、 可能只有经历过的人才懂吧。
纠结AB最根本的原因主要就是 视图 和 业务 是否分离的问题，分离后需要自行管理模块，这就需要框架，不分离则一把梭
A，B 结合是正统！ 结合自己的实际来吧
パズルガ-ルズ 你去日本的googleplay搜一下或者日本区的AppStore搜
碧蓝+三消 
类似steam上那种三消么
哇，大家快出来看看奇观了，200层楼的帖子竟然都很和气地讨论技术，没有任何对喷和人身攻击，简直是社区奇观啊！
—本回复占据第200楼 —
占201楼，感觉A方案好点。
星星你个星星星星，开始喷
选择2，即使自己做也要有规范，要不然过几天自己写啥都忘了。利己利人
AB结合，
对于A， 预设甲只绑定组件和自己管辖的子节点，不绑定其余的预设。
对于B， 能用代码驱动就用代码驱动，B方便审查代码。
A提供了便捷的手段，但不能上升为理念， B还是为主的
B为主，A为辅 YYDS
这不给颁个年度最佳帖子