我们项目现在就有这种问题，有很多很大的预制体，里面结构一团糟。很多时候遇到一个bug，查找的时候，知道报错在xx函数，然而代码编辑器中显示这个函数的引用是0。然后就懵逼了，因为引用是其他某个加了点击事件的脚本里通过拖拽引用过来的，找那个button如同大海捞针。
-
你不认为 B 比 A 慢，而我之前说的慢的原因其中之一是 组件添加/属性赋值
你的回答：生成节点和组件的引用，和 组件添加/属性赋值 无关 -
B 能生成的节点和组件的脚本引用代码，为什么 A 不能？这里开发速度基本可以持平所以我之前没说这里
所以你现在想说什么？？B 比 A 快吗？我觉得我已经说的很清楚了，原因都标注出来了
还有组件化的精髓是 “组合” ，不要搞巨大组件，keep it simple。
再比如 有一个共用的组件 需要新加一个字段/引用， 那就加上，在代码里做下兜底，引用是空 就用 find / geChildByName 兜一下底。代码里做好注释说明
a 还有一个小优点 不要求 绑定的节点/组件 有相同的层级，有时候这种l灵活性会很方便
是我理解错了
我再举个例子， 比如Label， 我是自己做一个多语言组件，继承于cc.Label，支持富文本啥的，但是会把key写在组件里面， 这个就是你说的组件添加/属性赋值了吧， 用法是A方式
但是还有一种情景，Button，我是要通过自动化脚本， 判断是button的，在auto_xxx里面，导出一行代码进行绑定，因为这样可以更好的规范button的click事件，而且click事件跟节点名称相关，找的时候也很好找，
这时候用的是B
至于其他情景，主要还是要看哪一种方便，易懂，好维护。
有一些组件很适合直接绑定在组件内，因为独立，不耦合，但是button就不一样，并不独立，因为button的回调本质还是函数，还是代码，所以在编辑器里面绑定回调，就容易引起问题，
所以我觉得，我主要还是用B
补充一下：
至于一些自定义组件，比如红点组件、特殊显示要求（圆角shader）等等， 我还是倾向用B动态添加，几个优点：
a、其他人用，直接抄这段代码，前提封装好，用A也差不多，就是对封装要求更高，因为如果需求发生更改， 不确定改动的影响大不大
b、全局检索快，IDE一搜索就出来，哪里用看下代码就行
c、封装方便，可以快速制作通用接口， 跟a点差不多
d、错误排查快，我们首先拿到的是堆栈，可以快速定位，可是用A，报错点得往回找好几个可能才看到自己写的函数
1赞
很多人说a 的缺点感觉都是管路问题。
主程管理缺失，或者开发人员素质、水平良莠不齐。
-
协作问题，核心不在于拖不拖节点，而是场景、prefab 无法合并。总归得“加锁”，一个人改完另一个人在基础上改。
或者 将自己修改的部分 拖成prefab，拉取到最近的场景/Prefab 再把prefab 合并上去。 -
升级版本 绑定节点，组件也不是核心痛点吧。引擎API废弃，资源管理大改，实现修改 才是最难的吧。
-
按钮回掉找不到
这个就是项目规范的问题了。统一 onXXXBtnClick 一目了然。
b 方案相对于a 是擦屁股。
管理不善、混乱的项目用b比a强吧
是啊， 没毛病，B是在一定程度上，对A做的补救，因为没有人有办法保证你的团队写的代码风格统一，每个人都有自己的特点，我觉得这个是好的，但是放到一起，你看我的代码像
山，我看你的又何尝不是呢，
所以用B，做一定程度的规范
用A的，没办法保证，哪一天又有人回搞出超级节点，超级预制体，超级组件出来，到时候去修都来不及，还不如一开始就做好
刚审核过的，不是新发的，我先删了
GTA GTA GTA
如果方案B 那么creator的意义就大打折扣了，还不如回归2dx，creator就是因为有编辑器所以才开发简单，效率高，编辑器才是他的根本意义
编辑器不就是为了编辑预制体和场景比较方便吗？ 除非UE那种蓝图型的，其他引擎的框架不应该受编辑器绑定才是。
我们也是降引擎，都是用引擎绑定的，研究了一下2.x跟3.x的预制体结构，写了脚本一键还原的
重复率高的组件代码加载 预制体放一个脚本控制就好了 动态加载资源 自动生成路径 谁说cc.find 加载慢的 我是真的服 游戏逻辑比如物理 碰撞的 计算量比你这节点查找不知道大多少倍吧 还有每帧执行的逻辑的卡的时候就知道了 还一个个节点绑定的 我感觉这完全是新手吧 我看过比较大的手游的界面一个界面上千个节点 还不是全部放进去 你绑我看看?
上千个路径也是自动生成的呀，上千个拖拽节点当然也是自动绑定了，如果都不能自动绑定，那还搞啥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）只支持单开，导致编辑器效率太低
或者是怎么样的，可以跟我更详细的说一说。