Rails 和 Sinatra 怎么选？全栈与微框架的 Ruby 内战
Rails 大而全，Sinatra 小而美。本文从路由、数据库、视图、表单、测试、API 开发与后台任务全面对比 Ruby 两大框架，给出清晰的适用边界。
功能会持续膨胀的完整 Web 应用选 Rails；轻量 API、内部小工具、嵌入式服务（如 webhook 接收器、监控探针）选 Sinatra。判断标准就一条：你预计半年后要用的功能里，有几个是 Rails 内置而 Sinatra 要自己装的——超过三个就选 Rails。
一个文件 vs 一整套约定
Sinatra 的哲学是"框架即 DSL"：
require 'sinatra'
get '/hello/:name' do
"你好，#{params[:name]}"
end
一个文件、几行代码就是一个可运行的 Web 应用。Rails 则是一整套目录约定 + 几十个子系统的组合：路由、控制器、模型、视图、迁移、任务、邮件各有其位。Sinatra 给你自由，Rails 给你秩序——自由在五百行代码内是美德，超过五千行就变成负债。
路由与结构
Sinatra 路由即方法，直接在顶层 DSL 声明，适合路径少的应用；模块化写法（Sinatra::Base 子类）可以把大应用拆成多个小应用挂载。Rails 路由集中在 routes.rb，资源式声明 + 命名路由 + 约束条件，管理几百条路由依然井井有条。
数据库与视图
Sinatra 不带 ORM，通常搭配 ActiveRecord（独立使用）或 Sequel——自由度高的代价是迁移、配置都要自己接。视图支持 ERB/Haml/Slim，但没有 Rails 那套 helper 生态（表单构建、URL 辅助、CSRF 防护要么手写要么找 gem）。Rails 的 ActiveRecord + form_with + 全套防护是开箱即用的完整链条。
表单校验与测试
Sinatra 里表单处理是手工活：参数自己取、校验自己写（或引入 dry-validation）、错误消息自己渲染。测试用 Rack::Test 直截了当。Rails 的模型校验、表单对象、系统测试（Capybara）一条龙——写管理后台、内容系统时，这层差距就是数周的工时。
API 开发与后台任务
纯 JSON API 是 Sinatra 的甜点区：路由直白、依赖少、启动快，做微服务和内部接口非常舒服（Rails 的 --api 模式也在抢这块市场）。后台任务方面，Sinatra 可以挂 Sidekiq 但 ActiveJob 的抽象要自己适配；Rails 的 ActiveJob + Solid Queue/GoodJob/Sidekiq 是即插即用。认证授权同理：Rails 有 Devise/Pundit 成熟方案，Sinatra 要自己组 Warden 或手写。
常见问题（FAQ）
Q：Sinatra 项目长大了怎么办？
两条路：用 Sinatra::Base 模块化拆分继续演进（很多生产 Sinatra 应用就是这么活的）；或者趁业务模型还简单时重写进 Rails。一开始就在 Sinatra 里复刻 Rails 的功能（自己装 ORM、helper、表单库）是最差选择——那说明一开始就该选 Rails。
Q：Puma 跑 Sinatra 性能比 Rails 快多少？
框架层开销 Sinatra 确实低，裸路由吞吐高不少。但只要接上数据库，两者差距迅速收窄到可忽略。为性能选 Sinatra 之前，先确认瓶颈真的在框架层。
Q：学习路径上先学哪个？
先 Sinatra 后 Rails 是经典路径：Sinatra 让你看清 HTTP 请求-响应的本质，再学 Rails 时每个"魔法"都能对应到底层机制，知其然也知其所以然。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
