Ruby on Rails优缺点分析 - 实战经验分享

刚入行那会儿，公司项目全用 ref="/tag/2028/" style="color:#3D6345;font-weight:bold;">Ruby on Rails，当时觉得这玩意儿简直是开发神器。写几行代码，一个后台管理系统就跑起来了，连分页、表单验证都自带，像搭积木一样快。

比如要做个文章发布系统，模型、控制器、视图一路生成，migration 写完表结构，Rails 自动给你配好路由和 CRUD。不用手动配置一堆东西，rails generate scaffold Post title:string content:text 一行命令，前后端基础代码全有了。

class PostsController < ApplicationController
  def index
    @posts = Post.all
  end

  def show
    @post = Post.find(params[:id])
  end
end

这种约定大于配置的设计，省去了很多纠结命名和结构的时间。新手上手也快，团队新人第二天就能改接口。

用户认证用 Devise，图片上传用 CarrierWave 或 Active Storage，后台管理直接集成 Rails Admin。这些 Gem 稳定又文档齐全，比从零造轮子强太多。以前做过一个活动报名系统，三天时间加上测试就上线了，靠的就是现成组件多。

项目做大了以后，首页加载开始变慢。一个简单的聚合页面查五六张表，响应时间动不动就上千毫秒。加缓存、拆查询能缓解，但 Ruby 的运行效率摆在那儿，没法跟 Go 或 Node.js 比。有次搞大促，流量翻倍，服务器直接撑不住，最后只能加机器硬扛。

框架太“聪明”，隐藏了太多细节。比如 ActiveRecord 的自动加载机制，某个关联查多了，内存占用悄悄涨上去，排查起来费劲。还有升级版本时，经常因为底层行为变化导致功能异常，得花时间读变更日志一点点调。

现在新人都奔着 React、Spring Boot 去，愿意学 Rails 的少。我们组去年换人，面试十个前端出身的，八个没碰过 ERB 模板，更别说写 Helper 了。培训成本明显高了。

现在看，Rails 适合快速验证想法的小中型项目。创业做 MVP，或者内部工具，它依然能打。但要是追求高并发、长期维护的大系统，就得掂量清楚它的短板。

Ruby on Rails优缺点：用过三年后的真心话