Rails 和 Hanami 怎么选？Ruby 两大全栈框架对比
Rails 约定优于配置，Hanami 显式优于约定。本文从项目结构、路由、控制器、持久层、视图与依赖管理全面对比 Ruby 两大全栈框架，帮你判断 Hanami 的模块化理念是否适合你的项目。
追求开发速度、生态丰富、招人容易选 Rails（事实标准）；认同显式依赖、模块化单体、想让 Ruby 代码远离"Rails 魔法"选 Hanami。Rails 依然是默认答案，Hanami 是给有明确架构主张的团队准备的精致替代品。
同宗不同路的两个框架
Rails 自 2004 年定义了"全栈 Ruby Web 框架"：ActiveRecord、路由、视图、任务、缓存、测试全打包，约定优于配置。Hanami（前身 Lotus）走的是另一条路：同样全栈，但强调显式代码——依赖要声明、边界要清晰、魔法要少。两者都能建完整应用，分歧在代码组织哲学。
项目结构与路由
Rails 项目是约定目录：app/controllers、app/models，路由集中在 config/routes.rb，资源式 resources :posts 一行展开七个动作。Hanami 2 把应用拆成 slice（切片，相当于内置的模块化单体单元），每个 slice 有自己的路由、action、视图，边界天然清晰——大团队按业务域并行开发时，这个结构收益巨大。
控制器：Action vs Controller
Rails 控制器一个类承载多个动作（index/show/create……），隐式渲染、隐式参数，before_action 链处理横切逻辑。Hanami 的 Action 是一个动作一个类：请求参数在类上用 dry-validation 风格的 schema 显式声明，响应显式返回，依赖通过构造器注入。单看一个动作，Hanami 更长；看一整个项目，Hanami 的可预测性更强——不存在"这个 before_action 到底对哪个动作生效"的灵魂拷问。
持久层：ActiveRecord vs ROM
Rails 绑定 ActiveRecord，模型即表结构，开发效率无敌。Hanami 采用 ROM（Ruby Object Mapper）：Relation 管查询、Repository 管读写、Entity 是纯领域对象，数据层与业务层彻底分离。代价是概念多、上手慢、第三方生态薄——ActiveRecord 的 gem 海洋（分页、搜索、审计）在 ROM 世界大多要自己解决。
视图与表单
Rails 视图默认 ERB，helper 满天飞，表单有 form_with 与模型深度绑定。Hanami 的视图层同样基于模板但强调 View 对象封装展示逻辑，helper 不再隐式混入。两者都能配合现代前端方案（importmap、esbuild），Hanami 的显式风格在视图层同样体现。
测试与依赖管理
Rails 测试围绕框架约定（fixtures/FactoryBot、ActiveSupport::TestCase 或 RSpec）。Hanami 因依赖注入与边界清晰，单元测试可以不启动框架、不碰数据库——测试金字塔更容易保持形状。Hanami 的组件自动注册基于 dry-system，Ruby 元编程功底好的团队会觉得优雅，新手则可能迷失在"对象是从哪冒出来的"。
生态与现实考量
Rails 生态的优势是压倒性的：任何问题都有三个现成 gem，招聘市场深，文档教程二十年积累。Hanami 社区小而精，框架本身质量极高，但遇到冷门需求时"自己造"的概率大得多。选择 Hanami 意味着你买的不是生态，是架构纪律。
常见问题（FAQ）
Q：Hanami 性能比 Rails 快吗？
框架层基准测试 Hanami 确实更轻更快，但业务应用瓶颈在数据库和外部调用，框架层差距很少成为决策因素。选 Hanami 的理由应该是架构理念，不是跑分。
Q：Rails 项目能渐进迁移到 Hanami 吗？
没有平滑路径——两者从路由到持久层都是不同世界，迁移等于重写。想要模块化又不想离开 Rails 生态，更现实的选择是 Rails 自带的 Engine 或 packwerk 边界工具。
Q：什么团队最适合 Hanami？
Ruby 功底扎实、对 dry-rb 生态有好感、项目预期寿命 5 年以上且领域复杂——这类团队能把 Hanami 的显式架构红利吃满。快速试错期的创业项目请老老实实 Rails。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
