就是因为太全了所以不好用，定制不是那么直接。而且全也不见得是好事，你可能用不着那么多，但是每个都要照顾不要出问题。

框架太重了，一堆根本用不到的功能，导致一堆废代码，看着就头更疼，自己写登录注册也很简单吧

Devise 是一个非常非常优秀的开箱即用用户鉴权系统的解决方案，通常情况下简单配置即可。

如果定制起来，那就非常麻烦了，而且需要对 Devise 的底层实现有足够了解

比如异步发送 Devise 的各种触发式邮件，当然 SO 早有人踩过坑啦，但是如果让你自己想，绝对要花很久才能玩明白

PS：我对 Devise 深度定制到了重写全部控制器，还有在模型里也加入大量黑魔法代码，Devise 全部代码都读过了...然而现在仍然表示对 Devise 理解不够深刻...

默认好用，定制困难，但这也不是 devise 的错，因为它本身就是为默认为主 + 少量定制的场景设计的。

我觉得这个框架好就好在充分遵循 Rails 的 Convention Over Configuration 原则，常见的使用场景都提供，需要定制的也留下了覆盖的接口，文档那么多也覆盖了大量定制的场景，不知道你们说的定制是哪种程度的定制了

多用几次你就知道了，我的感觉是写 demo, 或者开箱即用，无需定制的需求用它非常方便，其他就算了。

会用的人说好，用不明白的人说不好控制！

之前没选 devise 自己写了，然后到后面发现很多 gem 都是只有 devise 集成的文档，自己写的就得多研究好久

因人而异

一个越是全面的工具，使用当中业务细节上可能与之冲突的地方越多。

同时，越是全面的工具，你如果不顺着它本身的设计理念去用，就越需要花精力与这个工具抗争，作各种修改。

以上两者结合得出的结论就是：越是全面的工具适应性越窄，越多情况下是不好用的。

所以我比较倾向于选用功能集小、简单的东西来一步步搭建产品。

@sandy_xu 只是一个工具而已，就算会用也要看场景。不妨谦虚一些，少做断言。

最近做的一个订制是注册的时候把默认的 email 验证改成 email 和手机号共用一个表单项，存数据库也是判断输入的是 email 还是手机号来分开存如不同的字段。登录的时候也是自动验证输入的是哪个字段。 这个订制大部分都参考文档做的，代码都写在 model 里，以后假如要做其他 model 的验证也不会影响，思路也非常清晰。 如果要用其他框架做可能就不是很好做了