Drupal 本身已经是非常强大的存在，它的优势已经为大家所熟知，尤其是选择 Drupal 的人更是被它的各种魅力所折服。但任何事物都会有它的缺陷与不足，Drupal 也不例外。而我们要把这个话题提出来讨论和交流，并不是打击 Drupal 或者是打击学习和使用 Drupal 的爱好者热情。而是希望能够理性的看到和承认 Drupal 的一些不足之处，并通过合适的方式方法来弥补它的缺陷和不足。还是那句老话，Drupal 什么都能做，但不见得什么都要用 Drupal 去做，明知是坑的地方，就不要蒙着眼睛往里面跳了。

　　以下对 Drupal 的一些缺陷和不足进行罗列和说明，并且也提供一些弥补、改善或者避开的方法，这样以后在遇到这些问题的时候能够更从容一些。

易学性与易用性

　　Drupal 在用户友好的层面上存在两大“不足”，分别是易学性和易用性。

　　Drupal 易学性上的不足是先天基因决定，它是面向“开发人员”的工具，而非面向普通用户的产品。要基于 Drupal 搭建一个网站或者是系统，普通用户入手之初最多只能安装和配置一些简单的模块，要想做到像熟手们说的那样“找到模块安装一下就好了”，那是不可能的。

　　如果想要对系统进行修改或者说是扩展，前期没有投入一定的时间去学习和了解 Drupal 的基本知识，除了面对一大片后台管理链接无所适从之外，新手们还能干什么呢？

　　Drupal 非常不容易学习，因为扩展的灵活性使其拥有了相对其它系统更为复杂的结构，添加新页面应该使用菜单系统、访问数据库应该使用数据库抽象层、添加修改模版要先学习模版机制，原本在其它系统下的经验到 Drupal 上来统统都不能用了 —— 使用 Drupal 的人少，与它的学习曲线、学习周期严重相关。这是 Drupal 的一个先天不足，但这些“化简为繁”的机制和抽象层最终给 Drupal 提供了无比强大、无可比拟的扩展性和灵活性 —— 所以对于慕名而来的 Drupal 的仰慕者们，Drupal 很强大，但必须要在熟练的人的手上，可以花重金请专业的团队打造世界一流的站点和系统，但切不可抓几个 PHPer 就妄想短时间内驾驭这匹野马。

　　PS: Drupal 功能性和扩展性的强大，以及学习曲线和周期决定了其自身的价值，一分努力一分收获，请走在 Drupal 之路上的各位谨记！！！

　　与易学性相同，Drupal 的易用性也是先天不足，一方面是因为它不是面向普通用户“开箱即用”的产品，另一方面是因为在用户体验“能用、易用、好用”的三级标准上，Drupal 的功能在很大一部分程度上都只是“能用”的级别。只实现基本的体验和交互，优点在于能够方便地在其之上添加需要的行为，缺点在于没有一个默认易用的行为，每个站点都需要付出一定的工作量。

　　易用性是 Drupal 的一项不足，但并非硬伤，相对其它一些不易扩展的CMS或者框架，Drupal 至少能够让我们更快的优先获得功能，至于用户体验和交互，对于熟手来讲也是手到擒来的事。

　　因为今天时间有限，后面的一些缺陷与不足先简单介绍一下，后续有需要了解的地方大伙再给我发邮件或者是留言咨询吧，先谢过。

兼容性

　　Drupal 大版本之间不提供向后兼容，即 D7 不向后兼容 D6，D8 不向后兼容 D7。根据 Dries 若干年前的博客（大概是2005年，记不太清楚了），说明了 Drupal 的新版本会选择同时期最新的技术，以保证 Drupal 走在技术的前沿，同时因为不提供向后的兼容，能够更好的保持核心的精简。

　　对于需要做大版本升级的个人或公司，在此的第一个建议是不要做大版本升级，因为确实必要性不大，但工作量可能惊人的可怕。如果实在要升级，同样从工作量出发，可以先行评估，然后从升级和重建中做出合适的选择。

性能

　　Drupal 在扩展性和灵活性之间需要做出平衡，模块化的架构和 hook回调系统则是站在扩展性这一边。强大的扩展性会带来性能上的损耗，但 Drupal 通过内置的缓存系统以及整合各种外部缓存、代理、加速来大幅提升性能。

　　有关扩展与性能的话题，我们在之前的视频里面有提到过，可以找找看。

模版抽象层

　　Drupal 的页面布局更多是通过区域分配的方式来执行，内容与内容框架（确定内容组织方式的HTML代码结构）混合存在一起，传统前端生成 HTML的方式在 Drupal 中难以得以应用。而内容与内容框架混合的形式也使得 Drupal 主题很难像 WordPress 那样做到主题的复用。

团队协作

　　Drupal 的团队协作应该算是 Drupal 各种抽象层的副作用，因为整个项目流程与传统网站项目不同，所以协作上也会出现一些难点。不过通过对 Drupal 流程有清晰的了解之后，能够找出不同职能的分界线，通过 Drupal 的方式来进行团队协作，问题就能够得以解决了