一个请求经过了哪些 Ruby 机制

先修：13、17、20、23、28。核心问题：常量加载、回调与核心类扩展如何成为 Rails 请求行为。实验入口：examples/ruby/labs/E01/run.rb。验收：自动加载前后状态、回调轨迹及二百、四百零一、四百二十二响应均通过断言。版本边界：CRuby 3.4.11，Rails 所选组件 8.1.4，仅进程内请求测试。

Rails 控制器看起来只有几个方法，实际请求还依赖常量加载、继承、类方法注册的回调、参数对象和响应编码。把这些行为全部归给 Ruby，离开框架后就会遇到方法不存在、文件没有加载、回调没有执行等问题。这个实验把同一份 Taskbook 领域代码接到真实 Rails 应用上，用请求结果区分语言能力和框架约定。

实验固定 CRuby 3.4.11，Rails 的 railties、Action Pack、ActiveSupport 均为 8.1.4。只安装请求实验需要的组件，不加载 Active Record，也没有数据库、后台任务或前端构建。具体间接依赖保存在独立 Gemfile.lock；框架补丁版本取自 Rails 版本记录。版本冻结描述本次实验环境，不代表所有 Ruby 与 Rails 组合都兼容。

完整程序位于仓库的 examples/ruby/labs/E01/。最终观察包括正常请求返回二百、缺少演示凭证返回四百零一、错误参数返回四百二十二，以及每个请求实际经过的回调顺序。请求进入 Rails 的集成测试会话，经过路由和控制器分派；它不打开 TCP 监听端口，因此不能代替反向代理、TLS 或部署后的网络测试。

blank? 不是 Ruby 的真值规则

在只启动 Ruby 和 Bundler 的新进程里，空格字符串不响应 blank?。显式加载 ActiveSupport 扩展后，同一个类获得了该方法：

1
2
3
raise if ' '.respond_to?(:blank?)
require 'active_support/core_ext/object/blank'
raise unless ' '.blank? && false.blank? && !0.blank?

这段探针在加载 Rails 之前通过子进程运行，避免前面请求加载的扩展污染判断。若在已经启动的 Rails console 中观察，方法早已存在，无法据此证明它属于 Ruby 核心。方法所属的加载环境也是实验条件。

Ruby 条件判断只有 false 与 nil 为假，空字符串、空数组和零都为真。ActiveSupport 的空白判断则表达另一套接口约定：空格文本与 false 可以被判断为空白，零不是空白。这些谓词没有修改 Ruby 的条件分支语义。把布尔配置交给 blank?，可能把显式关闭与未提供混为一谈；领域输入应按字段含义判断，而不是统一调用某个方便的方法。

ActiveSupport 扩展指南说明了按需加载扩展的方式。对于可独立安装的库，显式依赖和明确 require 可以避免“应用里能跑、单独测试失败”的偶然成功。本系列 Taskbook 的核心校验继续使用字符串编码、空白检查和枚举值约束，不要求宿主先加载 Rails。

文件名如何变成控制器常量

控制器放在 app/controllers/tasks_controller.rb，定义 TasksController。应用初始化时设置实验目录为根目录，关闭 eager load；首次请求之前，程序断言控制器路径尚未出现在 $LOADED_FEATURES。请求结束后，同一路径必须出现。这里验证的是按需加载确实发生，不能只凭“请求成功”推断加载方式。

1
2
3
4
5
6
7
8
app = WorkshopApplication.initialize!
app.routes.draw { get '/tasks', to: 'tasks#index' }
controller = File.join(__dir__, 'app/controllers/tasks_controller.rb')
raise if $LOADED_FEATURES.include?(controller)

session = ActionDispatch::Integration::Session.new(app)
session.get('/tasks', headers: { 'X-Lab-Key' => 'local-test' })
raise unless $LOADED_FEATURES.include?(controller)

Ruby 提供常量和文件加载机制，Rails 配置自动加载器，把目录结构映射到常量名称。文件路径是框架输入的一部分：随意把控制器改成不匹配的文件名，不能指望类体语法正确就获得相同结果。自动加载减少显式 require，但增加了命名与目录布局必须一致的约束。

按需加载与重新加载还需要分开。这个程序只初始化一次，不修改源文件，也没有触发 reload。它证明第一次请求能够找到控制器，不证明跨请求热更新、更换类对象或缓存旧类引用的行为。对这些问题，应根据 自动加载与重新加载指南另外设计实验。尤其不能把保存到全局变量里的类对象等同于后续常量解析得到的对象。

要验证框架替代了哪一步手工操作，先记录操作前的状态，再触发最小入口，最后检查状态变化。只检查最终业务结果，可能漏掉预加载、缓存或手动 require 带来的替代路径。

回调注册与普通方法调用不同

控制器类体调用 before_action 和 around_action。它们不是 Ruby 关键字，而是继承链上可调用的框架方法。注册完成后，框架在处理请求时组织执行顺序。单独创建控制器对象然后调用 index，并不等价于经过完整请求分派。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
before_action :authorize_lab
around_action :record_action

def authorize_lab
  request.env['lab.events'] = ['before']
  head :unauthorized unless request.headers['X-Lab-Key'] == 'local-test'
end

def record_action
  request.env['lab.events'] << 'around-enter'
  yield
ensure
  request.env['lab.events'] << 'around-exit'
end

正常请求记录 before → around-enter → action → around-exit。缺少演示请求头时，前置回调设置响应，观察到的数组只有 before；行动方法没有执行，后续 around 回调也没有进入。这里的中止依据是框架响应状态，不是把任意返回 false 都解释成通用的停止规则。

around 回调中的 yield 是普通 Ruby 块调用，ensure 则提供清理语义。参数转换失败后，行动方法把 ArgumentError 转成四百二十二响应，around 的退出事件仍然出现。这个观察不能推出数据库事务一定回滚；回调包裹动作与事务提交属于不同契约，后者需要数据库实验才能回答。

事件数组保存在当前 request.env，避免类变量在请求之间累积状态。本地演示凭证仅用于制造可观察的前置拒绝路径，不能作为真实认证方案。回调隐藏了部分控制流，所以测试既要断言状态码，也要断言“不该发生的行动没有发生”。控制器指南提供了前置、后置和环绕回调的具体行为依据。

参数适配仍然需要领域校验

查询字符串进入控制器后，params 是框架参数对象。它支持一些类似 Hash 的访问方式，但不能把它当作普通 Hash，也不能认为 URL 中写了数字就已经获得 Integer。实验先要求 min 为字符串，再用严格的十进制转换交给 Taskbook：

1
2
3
4
raw = params.fetch(:min, '1')
raise ArgumentError, 'min must be a string' unless raw.is_a?(String)
tasks = Taskbook.filter(Taskbook.sample_tasks, min_priority: Integer(raw, 10))
render json: Taskbook.summary(tasks)

字符串类型判断处理 min[]=1 这类结构化输入；没有这一步，Integer 对数组的失败类型可能越过只捕获 ArgumentError 的响应边界。严格转换处理 min=nope，领域函数再处理数字不在一到五之间。HTTP 适配层负责请求结构和响应映射，领域层负责合法任务与筛选选项，这样命令行入口仍能复用同一规则。

测试中正常响应的 total 为三。无凭证得到四百零一，非法文本与数组参数分别得到四百二十二。测试并未覆盖所有参数编码、过大请求体或攻击流量，因此结果是一个最小适配器的行为证据。生产接口还需要依据自身协议限制请求大小、处理错误信息并建立真正的身份校验。

安装与复现

测试会话还保留请求对象与响应对象，因此可以同时检查响应内容和框架执行状态。只检查 JSON 里的 total，无法区分错误路径是否也用了二百状态；只检查状态码，又可能漏掉返回旧缓存内容的错误。实验对成功请求读取正文，对拒绝请求读取事件数组，两种观察针对不同缺陷，不能互相替代。

应用配置把允许的 Host 限定为集成会话使用的域名，并把日志写入内存。前者避免测试环境中的主机校验提前拒绝正常样本，后者避免把临时请求日志写进仓库。它们属于显式实验配置，不应直接复制为部署配置。若新增域名、日志目的地或异常展示方式，应该把这些设置也纳入接口的运行条件。

没有数据库让这个实验更容易定位失败：路由没找到、控制器没加载、参数转换错误和领域校验错误都有各自可观察的位置。引入持久化之后，应继续维持这种边界，把数据库行为放在另外的集成测试里，而不是让一个最小请求同时承担迁移、连接池、事务和响应格式的验证责任。

进入 E01 目录，以 Ruby 3.4.11 执行以下命令。独立依赖目录与主实验工程分开，提交锁文件即可保存本次解析结果，安装产物不进入版本管理。

1
2
3
cd examples/ruby/labs/E01
BUNDLE_PATH=.bundle/vendor bundle install
BUNDLE_PATH=.bundle/vendor bundle exec ruby run.rb

从主工程运行 bundle exec ruby labs/E01/run.rb 也可以。入口会清除继承的 BUNDLE 变量、RUBYOPT 和 RUBYLIB，再用该实验的 Gemfile 与独立安装目录重新启动。这个重新启动很重要：同一进程不能先激活主工程的 Rack 版本，再假定另一份锁文件能够撤销已激活的依赖。

evidence/E01/run.txt 保存执行输出，requests.json 保存解释器、框架版本、状态码与回调数组。安装本身需要网络；已安装依赖后的请求测试只在进程内运行。框架测试能力和实际部署能力应分别记录，不能因为没有开放端口就把集成请求叫作线上验证。

练习与适用边界

练习一：将控制器文件复制到临时目录，故意让文件名与常量名不一致，再请求同一路由。保留错误类、完整失败输出和未执行的行动证据。修复名称后重新请求，解释这次失败属于加载约定还是领域业务。

练习二：增加 min=0、min=5 和 min[]=1 三个请求，分别断言响应状态与计数；再移除字符串类型检查，观察数组输入是否变成未处理异常。恢复检查后，确认同一个测试能从失败变为通过。

问题 判定位置 本实验的证据
方法来自哪里 新进程加载前后 blank? 探针
常量何时加载 首次请求前后 已加载文件列表
回调是否跳过行动 请求分派 拒绝请求只有 before
输入是否满足领域规则 参数转换与 Taskbook 成功与两种错误参数

这个小型应用覆盖框架接入语言机制的过程；Active Record、事务、后台任务、热重载与生产服务配置都不在实验范围内。

系列导航

导读 · 上一篇：39：综合交付与可复现使用 · 下一篇：E02：RSpec、契约测试与可重放的生成式测试 · 完整源码包