上千个路径也是自动生成的呀，上千个拖拽节点当然也是自动绑定了，如果都不能自动绑定，那还搞啥A，直接B得了
666,都是大佬~~~~~
推荐第二种方式, 方式1虽然看上去灵活，但如果团队里面的每个人可以任意的在任何节点上挂脚本，绑定数据,会导致如下问题:
1: 团队协作的问题，成员A，改了A脚本，加了个编辑器绑定，并绑定好数据，同时成员B改了A脚本，加了编辑器绑定，绑定好数据，两个人一合并，总有一个人会要解决冲突，重新绑定;
2: 代码维护的问题: 允许任意地方挂代码，导致我们找代码流程的时候，被迫要每个节点的打开，来找它上面有哪些代码，有时候动画里面挂一个事件调用，维护的时候很难找到,对于代码维护来说是恶梦;
3: 方式2看上去复杂，但是主干流程清晰，通过代码搜素可以完整的找出对应的流程逻辑，方便代码维护与扩展。
4: 方式1的版本升级，资源更新与部署等，都可能会引发不可预知的问题，特别是版本与api的升级。
5: 性能与问题不好定位，很难方便的隔离关闭掉某些功能，比如定位怪物的AI性能，要关闭掉所有怪物的AI代码。
做项目还是要有一些规范，绝对的自由等于没有自由,能用代码搜索就能维护的项目绝对比资源和代码混合在一起要清晰和好维护。
…
2赞
350楼，终于看完了 
借这个楼，我想了解下，针对这两个方案，creator 能为你们提供什么帮助或者功能上的支持吗？
我先开个头
比如针对方案1 ，我理解大家反馈的比较多的述求是节点面板上不能直观看到挂了脚本的节点，这部分节点希望差异化显示，可以在界面上直观看到挂了脚本的节点。
针对这两种方案，还有什么意见建议，可以继续往下接。
美好的幻想 如果能像vscode搜索跳转一样丝滑
那才是真正做到了编辑器的职能
很多时候不是选择了方案二 而是被迫
往往代码工程化了 编辑器却拖后腿了。。
我是不是可以这么理解
- 目前编辑器搜索不好用（比如太慢，不精确或者xxxx）
- 目前场景（prefab）只支持单开，导致编辑器效率太低
或者是怎么样的，可以跟我更详细的说一说。
端午节快乐 
可以单独开一个帖子让大家讨论 这个帖子太长了应该结帖比较好
creator 可以借鉴一下laya 的那个prefab脚本，根据prefab内节点路径，自动把节点和组件绑定对应类变量。
这个是方案2里面纯代码实现比较需要的地方。纯代码实现一般都会findChild（或者用各种方便的变种例如attribute）来获取节点和组件到类成员变量上，有自动化工具当然更方便。
其实你说的这些都有解决方案，理论上绑定和代码是一样的，绑定也是代码的一部分，自动化绑定基本能解决80%的问题，而且绑定本身就是一种解耦，换皮调整节点树也是一种煎熬
我现在用的1方案，只不过都是写的插件和自动化工具，这是我遇到的挺影响操作体验的几个问题
- 每个prefab改动都需要打开再关闭（prefab缺少预览，没法批处理操作组件）
- 没法精准的知道每个节点树的组件和类型（缺少标记/类型图标）
- 插件系统灵活度不太够，并且批量处理总会莫名其妙的报错（一般延迟操作就好了）
我支持A方式
还有兄弟们实践出真知
自己有一定量级运营级的项目在线上跑
并且自己的方式能高效开发和维护日常的任务
这就够了
管别人怎么开发的干嘛，更不要去说服 别人。
AB本身没有绝对的对错
其实之所以那么多人说a不好的原因不是a真的不好，而是每次引擎升级兼容性过于差了才有这么大的怨念。
至于a其他的缺点大部分都是和开发过程中的不合理有关，比如预制件做的时候过于粗放不够细化，什么东西都塞一起。熟练掌握好各类设计模式a当然没问题了。
说到底还是要考虑很多原因，比如游戏行业很多人都是半路出身或者说出了学校就几乎把知识点全部还回去的，很多惨遭假敏捷开发迫害的，种种原因都会让项目质量得不到保证。而b最大的优点就是项目质量的下限会比a高，代码质量再差，堆的屎山再高，总归和a相比塌了的风险更低
- 丢失资源的节点在节点树中直接表示出来(变红等)
- 更强的搜索功能.允许路径,同文件夹名时显示路径,能搜图片更好,或者可以内嵌相似图片寻找功能.
3.更流畅的资源文件树显示. 参考vscode,在一个很深的目录时,自动显示上级目录,并且可以方便的点击折叠. 游戏的资源一般都不少,光是翻来覆去的查看资源就很累了. - 预制体多开.不必多说
- 系统自带的隐藏/显示节点,锁定节点,快捷键
- 实时节点树.不必多说一直实验室的功能.
2赞
说到图片,我平常要用Billfish辅助查看寻找游戏资源,billfish能按颜色,标签搜图,能自己按各种条件排序…cocos能内嵌一些的话肯定会大幅提高效率.
至少,设计上,同等开发量的情况,参考一些高效的方法也能提高很多效率
还有 unity在image上可以直接点开图片资源库,直接替换,在做ui的时候这个功能不错的
还是那句话，实践出真知。
我不参与争论谁好谁坏，
两个方向没有绝对对错。
如果谁进到大公司，贯彻B方案 自己从零到一做到一款稳定上线运营 并有一定量级的产品，
技术细节敢在司内接受所有技术的pk，
并且工作流和人员技术管理都依赖B方案有一套公司认可的方法论，
那他也一定是对的。我没法不认同。
说到这些 在项目上2种方案都已经使用过
上份工作使用的是A方案，项目定位是重度卡牌，目前工作使用的是B方案，定位也是重度卡牌
在使用A方案时，每个脚本中所new出的对象都需要在该脚本的关闭生命周期里释放掉
在使用B方案时没有在该脚本关闭生命周期函数里释放（我们当前项目没有做这一步）
比如:
this.items = []
this.items.push(instantiate(Node))
那么在A方案中则会：
destroy(){
for(let i = 0;i < this.items.length; i++) {
this.items[i].destroy()
}
}
在B方案中则不存在这步操作
是因为挂载的脚本的原因吗
没有去研究过为什么要这么做
也没有去研究过不这么做会怎么样
但是一直存在这个疑问
主要看你怎么做吧，毕竟方案b是脚本去绑定节点，节点销毁了控制的脚本还在，所以就算销毁也是自己处理不可能走生命周期函数了，如果这个脚本一直重复使用，new出来的对象管理的得当一直在重复使用的当然不会销毁了。
a是脚本跟着节点走了，节点都销毁了脚本当然也要跟着走了，那你new出来的对象又谈何复用呢，所以肯定要销毁掉。
反过来说如果a的节点不是销毁的而是隐藏等手段保存起来管理的那也可以不销毁，b如果脚本对象也会触发销毁逻辑那你还是得写好对象的管理、销毁逻辑。
但说实在的，能写destroy的逻辑尽量写，就算明知道当前这个情况不存在脚本销毁，但你也无法预料未来发生的事情，万一未来分包把这块逻辑分出去变成不是必须的功能也要销毁了呢，还有各种原因