这个问题，在我刚刚接触unity的时候，也想了好久，头都想痛了。归根到底是编辑器内置的那套组织结构和脑子里面原有的编程范式不一致的原因。
后来我想通了，不依赖编辑器了。这样任何架构根据情况都可以使用。就算是做和编辑器一样的Entity-Component模式，Entity也是自己的类，并且也会用一个ViewObjectComponent去保存编辑器的node。
编辑器里面挂组件，可以看成资源里面带逻辑，面板上填属性拖引用，可以看成变相的依赖注入。预制体挂组件的性质，其实和动画状态机里面带事件逻辑一样，都是资源过度带逻辑。
而我的设计原则是，资源里面尽量少带逻辑，真的要带也只能带资源的规范性质的逻辑（例如节点路径这种类似规范性质的是可以带的），以免逻辑依赖到资源上。也尽量减少不可代码追溯的依赖注入，以免找不到初始化的逻辑。
所以一般来说我是选择代码式的。
而且 场景 的描述文本 咱还看不懂！
个人觉得 A B都太极端了，我是中间流
一个场景 一个脚本，其他都是 ui组件
这似乎不太够，也给预制体也要配一个脚本
目前我的项目没涉及到多人开发， 所以自己感觉还可以
场景描述文件 不用比对，直接覆盖，只需要比对脚本即可！
但我依然搞不清 多人协作时 场景描述文件 怎么处理? 难道是靠个人约束?
我也选B。
A
优势：开发小功能快。（但是在有成熟框架的时候，这个优势基本可以忽略）
缺点：
1.引擎一个bug，可以让你绑的代码丢失重新搞。
2.代码不好审查，因为你阅读代码的时候很难找到代码挂在了哪些地方。尽管有各种反查工具，但是这个查找效率低，大大影响工作效率。
3.多人开发绝对的噩梦。你根本不知道这个代码用在哪，用来干什么的，改了之后不知道多少预制体受影响。
4.引擎升级基本不敢想，整个项目基本都要大动干戈。
B
优势：
1.代码审查方便，ide一搜就可以搜到。
2.引擎bug只影响预制体的美术编辑，对代码几乎没有影响，顶多就重新拉一次主入口代码挂载节点。
3.引擎升级基本只需要调整更新的部分api，不需要重新给预制体拉代码。
4.多人开发方便，减少提交代码时的冲突。
缺点：
1.需要手动挂载组件。
2.需要手动获取预制体上的某一节点。（这个用自动生成工具就可以了，像下面的这种）
总结：
1.小游戏不考虑维护，不考虑做大，仅一人开发，功能简单的就用A
2.大游戏需要长期维护，需要不断增加功能，多人开发，功能复杂就用B
生成代码的引用这个回复，对于 uuid 丢失的问题，我在 2.x 经常遇到，3.x 一次都没遇到
我之前也做过这种插件，但是缺点和楼上说的一致，只有运行时才会知道节点树路径错误
https://forum.cocos.org/t/topic/130305/11?u=1226085293
事实上 A 的缺点是可以解决的，我上面已经说过了，只需把引用资源和直接加载预制体的方式改成调用组件脚本内的静态 open/close 函数即可，但是目前只看到我一个人这样做 
3.x我也经常遇到uuid丢失问题，当然不仅这个问题，变量名修改也要重新绑定。
节点数路径不一致的问题其实只要做个监听预制体修改的插件就行，只要预制体更改，就自动生成，这样就不会对不上节点树了。A方式绝对不适合多人开发，不要说多人了，只要项目大一点，过时间久了，完全不知道这个代码被哪些预制体引用。只要是项目需要长期运行维护的，B的优势会更大。
B 方式通过查找引用代码
A 方式也是有查找引用，所以有什么不同呢？反而 B 方式要多写一堆代码
另外只有工具脚本才会被多个预制体引用
说说复现方式？
你挂预制体的代码引用查找很慢的，并且你挂预制体上的代码，你怎么审核？对面提交代码你难道读他uuid一个一个找他挂了什么代码？如果用B方式，我对比差异一眼就看到他挂了什么代码上去了，这个预制体他引用了什么代码一眼明了
偶发的，一般就是预制体里引用其他预制体然后有时候就会触发，触发几率不大，但是只要触发，知道的人可能知道可以把child为null的清掉恢复，不知道的人只能还原重新做
工具代码一般都是初次才会审查，之后的审查有什么意义吗？难道不是审查业务逻辑而是审查挂了什么工具脚本？
可以看看这个，报错基本一致，现在知道解决方法就是把为null的child删了可以恢复，以前不知道，这么一下你整个预制体都没了
https://forum.cocos.org/t/topic/141509
从2.x用到3.x，天天用，只遇到升级出现问题，而升级出现问题的是节点属性而不是组件属性
就是审查业务代码呀 ，你审查业务逻辑难道不要看他改了这个代码，会不会对原有挂有这个代码的预制体有什么影响吗？那这个时候你怎么确认呢？
这个问题是不管挂不挂脚本都可能会出现的问题
是的，审查业务代码，那么 A，B 两种方式有什么差异？同样都可以跳转代码，只是B的工具代码看不到挂载的部分
而A的工具代码挂载都是固定的，那么有什么特别好的地方？
你这里说的缺点是 不知道这个代码被哪些预制体引用，但是事实上这个缺点是只有工具组件才会存在的。但是也可以通过查找引用的方式找到
那么 A 方式
-
审查代码可以直接跳转（排除工具组件，你上面说过）
-
查找预制体有字符串路径，也可以编辑器查找引用
-
查找工具组件可以通过编辑器查找引用
而预制体出现问题的是升级和撤销，无论你是用 A/B 两种方式都会出现
请说下A还有哪些问题？
如果限制一个预制件只挂载一个ui脚本，或者按一定的规范挂载，并且节点的绑定在代码里面find,不是通过编辑器拖动，确实A也没啥问题；
我见过有的项目，一个预制件里面挂了很多业务的脚本，节点都是编辑器拖上去的，真的很难维护
不管那种流派存在即合理不用争了，AB的好用都是建立在有一套规范的前提，大家萝卜白菜吧
你查找组件挂载哪些预制体上你用的什么工具？我用ide一查addcompoent(XXX)就可以查到一切，并且可以看代码的逻辑上下文阅读。而你用工具查XXX组件查到了20个各种名字的预制体，然后我又一要把这20多个名字的预制体一个一个的放到ide全局搜索读上下问代码，你觉得这样审核效率能高吗？