控制器

这一课你将能做到

1. 写出符合 RESTful 惯例的七个控制器动作，并正确处理成功/失败两条路径
2. 用 Strong Parameters 挡住批量赋值攻击，说清楚 require 和 permit 的分工
3. 用 before_action 回调消除重复代码，实现登录校验和数据预加载

为什么要学

控制器是 MVC 里的「交通警察」：接住请求、调取数据、决定渲染哪个视图或跳转到哪里。它的质量直接决定应用的边界清晰度——控制器里混入业务逻辑，三个月后就是一团谁都改不动的乱麻；控制器保持「薄」，业务规则全部在模型层，代码才能长期演进。

对比本站：Spring Boot 的 @RestController 通常直接返回 JSON 给 Next.js 前端；Rails 控制器则同时承担「渲染 HTML 页面」和「处理表单提交后重定向」的职责，respond_to 还能让同一个动作按请求格式返回 HTML 或 JSON——一个控制器服务两种客户端。

先建立图像

一个标准 create 动作的「双路径」心智模型：

表单提交 POST /articles
        │
        ▼
  @article = Article.new(article_params)
        │
        ▼
   @article.save ?
    ╱          ╲
  成功          失败
   │              │
   ▼              ▼
redirect_to    render :new,
@article       status: :unprocessable_entity
(看详情页)      (回到表单页显示错误)

记住这张图，90% 的 CRUD 控制器都是它的变体。

跟着做

步骤 1：生成并通读控制器

bin/rails generate controller Articles

app/controllers/articles_controller.rb：

class ArticlesController < ApplicationController
  def index
    @articles = Article.all
  end

  def show
    @article = Article.find(params[:id])
  end

  def new
    @article = Article.new
  end

  def create
    @article = Article.new(article_params)
    if @article.save
      redirect_to @article, notice: "文章创建成功"
    else
      render :new, status: :unprocessable_entity
    end
  end

  def edit
    @article = Article.find(params[:id])
  end

  def update
    @article = Article.find(params[:id])
    if @article.update(article_params)
      redirect_to @article, notice: "文章已更新"
    else
      render :edit, status: :unprocessable_entity
    end
  end

  def destroy
    @article = Article.find(params[:id])
    @article.destroy
    redirect_to articles_path, notice: "文章已删除", status: :see_other
  end

  private

  def article_params
    params.require(:article).permit(:title, :body)
  end
end

步骤 2：理解 Strong Parameters

表单提交的数据长这样：

params = {
  "authenticity_token" => "...",
  "article" => { "title" => "标题", "body" => "正文", "admin" => "true" },
  "commit" => "保存"
}

注意攻击者多塞了一个 字段。如果没有白名单， 会把 一起写库——这就是「批量赋值漏洞」（Mass Assignment）。