不论是从官方手册，还是各种第三方教程，几乎涉及到的，都是讲如何使用U3D，以及U3D的优点。
虽然我是用的一个让步语气，但请不要否认U3D的这些优点，它们的确存在。 但对于一个引擎的特性来说，优点与缺点总是共存的。
你可以从网上了解到所有优点，但是，你很难真正体会到U3D的缺点，除非你自己被坑过。 今天，我就来细数一下U3D的缺点。 这些缺点，仅针对大中型项目。 小型项目，U3D的优点可以充分利用。
是不是猛的一看，全是缺点。 不要怕，想看优点的朋友，走这里 Unity3D使用经验总结 优点篇
一、环境
U3D的环境可以说是非常OK的。一体式的感受，让所有工作都无缝地进行。 真要说它有什么缺点，还很难找到。 但有几个地方，不得不说。
1、U3D默认不支持多项目，每次打开场景，则会关掉当前场景，再打开下一个场景。 而双击U3D的启动图标，又会自动打开最近一个项目。 想要解决这个也还好办 在快捷方式后面加上 --project即可。 加上后，每次编译时会有一个提示，这个无关紧要。
再试试双击U3D的快捷方式，是不是会让你选择项目啦。
2、多个U3D版本不易共存，网上也有人提供了解决方案。但是，这始终不是太爽的一件事。
3、编辑器未和执行环境分离，若要DEBUG，必须启动U3D编辑器。 而很多时候，对于程序员来说，是不需要的。 它们只是想改改代码，然后编译，执行。 或许，U3D可以通过命令行提供一个较轻量的启动环境。
4、如果代码中出现了死循环，那就只有强行结束U3D，然后再开。 中间如果忘了保存，那刚刚做的场景编辑工作，就洗白了。
二、开销
基于Mono的运行环境，导致引擎起步价就比别人高。初始化时间过长。 这对于中高端机来说，是感觉不到的。但低端机，相比之下，就显得尴尬了。 而这一情况，对3D的影响还好。但对于一个小型的2D游戏来说，就会被人误认为，游戏做得不够好。
U3D虽然提供了原生的2D支持，但是其本质仅仅是在运行期锁定了相机，集成了BOX2D物理和2D碰撞生成器等东西。 运行时期的起步价开销，与3D是等同的。
三、代码驱动的开发模式
不管是官方示例，还是一些入门教程，都是以代码驱动的方式来引导大家熟悉U3D。 当然，代码驱动方式也确实很方便，同时更能章显U3D的强大。
对于一个小项目来说，代码驱动无疑是最便捷的操作方式。
但是，对于一个大型项目来说，代码驱动的结果则是BUG频繁，且很难逐一解决。 同时，对策划要求较高，策划需要知道不同对象应该挂什么样的脚本。 而对于代码驱动的开发方式来说，编码的人，最好就是策划。为不同的对象，使用脚本定制特定的功能。
因此，使用U3D做大型项目的话，还是得需要退回到经典的数据驱动模式。 数据驱动模式则正好没有代码驱动模式面临的问题。同时，数据驱动才能更好地做出网络游戏。
关于这个问题，我想等有时间了，专门弄一篇文章，向大家表达一下我心中所想。
在这里，简单地提一下脚本挂接需要注意的地方
U3D的组件思路是要一直沿用的，如果脚本不挂在对象上，那就失去了这个NB的特性，现在，我们要决定怎么样挂。我的思路是，对于一个对象来说，如果是对其能力进行扩展的，那就可以将这样的特性挂在对象身上。 反之，如果是决定游戏流程的，那这就应该是普普通通的代码，不能挂到对象身上。
下面，举一个简单的例子。 玩家走到一个触发器上，触发器触发，然后，玩家移到新地图。
首先，触发器本身是一个对象，它会检测是否有对象进入它，如果对象 玩家，那将会被传送。
对于一个普通的gameobject来说，是没有检查对象进入和触发能力的。 那，我们可以将它的COLLIDER弄成TRIGGER。 但是，一个对象的RIGGER触发的检测，只能是在挂在它的对象脚本里做。
按我们上面说的原则，那当脚本里检查触发后，我们就不能直接操作玩家。 而是应该将这个事件抛出，由逻辑来处理。
于是，我们可以写一个事件类，这个事件类负责管理所有事件，然后感兴趣的对象，可以来对里面的事件进行接收和处理。
我们还需要一个TrigerDetector来做所有触发器的挂接。 剩下的事情，就是真正的游戏逻辑来做了。
上面是单机的情况，那网络的情况，又怎么做呢。 这就是数据驱动的魅力了。
对于这个触发器，我们可以挂接一个teleport的脚本，这个脚本什么功能都没有，只有一些变量，如目标地图ID等。另外，我们还需要将这个对象标记为SERVER对象。
然后，我们需要扩展编辑器，将场景导出。标记为SERVER对象的，则导出到SERVER使用的数据文件，没有标记为SERVER的，则导出到客户端的数据文件里。
然后，前后两端进行加载和操作。至于如何导出，下面有简单说明。
四、所见即所得
咦，这不明明是优点么。为毛又成缺点了。
其实，这确实是优点，而缺点其实不是因为它，而是因为U3D采用二进制存储场景文件。那多人协作的时候，SVN冲突可是一桩接着一桩的。
解决这个的办法也挺简单，我们扩展一下编辑器，将对象导出成非二进制格式不就成了么。然后再在游戏里面，重新加载。
思路是这样，要实现这个中细节，其实也挺麻烦的。我们公司的编辑器虽然功能不多，界面不美，但是却优雅地解决了这个问题。
这套方案也不是一两句话能说清楚。 总之，记住，这里是个坑。
既然提到这里了，如果不说点具体解决办法，可能有人说我是装B了。 那我说一个能够一定程度上解决冲突的办法。
1、场景中所有对象，使用prefab。 不能有非prefab出现，且不能修改prefab的任何属性
不能修改属性的原因是为了保存的时候简单，如果大家属性都一样的话，那我们只需要存它的缩放，旋转，平移以及对应的prefab名字就可以了。 遇上需要不同属性的东西，那新建一个PREFAB
2、扩展一个编辑器功能，将场景导出为XML或者JSON什么的文本格式
这个文本格式，保存了所有的对象信息，每个对象信息包含缩放，旋转，平移以及对应的prefab名字。 当然，这不是死的，如果有其它需求，可自行添加。比如，对象的初始active状态
3、新建一个真正的场景，里面只有一个GameObject对象，这个对象只挂接了一个脚本，这个脚本的初始化，就是调用游戏逻辑的初始化，这个脚本的UPDATE，就是调用逻辑的UPDATE。
这其实就是一个MAIN入口。 你的游戏逻辑应该是与具体场景无关的。 你只需要加载你先前导出的文件，然后对所有对象进行实例化即可。
这个是解决SVN冲突的第一步，同时也是数据驱动实现的第一步。
关于游戏的增量更新之类的坑，并不是U3D特有的，通常只有两个解决方案，一个是数据和代码分离，以减少更新压力。 另一个是纯脚本，实现所有功能，包括资源的加载什么的。 不管采用何种方案来应对这个问题，数据驱动是必然的。
这也是我入手U3D的原因，因为通过编辑器扩展，我找到了数据驱动的解决办法。
其实，最想说的两个问题都说了，一是数据驱动，二是SVN冲突解决。但U3D肯定不只这些坑。 但那些坑，都是很具体的，通过具体需求才能解决的。
上面讲到的，是所有项目都适合的坑。希望对大家有帮助。