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全局搜索读上下问代码，你觉得这样审核效率能高吗？
是的，只要项目做大，做到后期这个问题就越来越明显，拖组件只适合那些小项目，那种一眼就看出这个代码在哪个预制体那种，一个组件只对应一个预制体的那些小项目随便做都可以，但是一个预制体10几个组件，一个组件被20多个预制体引用，这种情况下代码根本无法阅读
这其实是一个管控粒度的问题，在多人协作时，部分场景下A不满足需求，部分场景AB都能满足需求，但是B更优。
举两个简单的例子：
- 项目组维护的多个项目有部分相同的UI逻辑，需要提取公共的UI类，此时需要将预制体与脚本完全分离，此时A不满足需求；
- 组员负责项目中的局部功能开发时，在遵循一定规范的情况下（比如命名，文件夹结构，基类继承等等）采用A方式十分简单快捷，但是在代码剔除和代码规范检测方面，B方式更利于自动化工具的接入；
所以划分好粒度，小功能方式A一把梭，公共与大功能还是B好维护一点
业务也分很多种啊，实现一个通用的复用滚动框也是业务，那复用滚动框就会被多个地方使用了。只要有滚动框的地方就需要拉上。
A方案分离也可以直接继承基类，所以为什么不满足？
说个示例？我一直都用 eslint，代码规范已经保证了，那么你说的代码剔除 B 有什么好处？举个例子？