CGI（Common Gateway Interface）是Web开发历史上最早的服务端动态内容方案之一，Ruby早期的大量网站都是用cgi.rb标准库构建的。然而Ruby官方在1.9版本之后逐渐淡化了对CGI的支持力度，Ruby 3.x时代整个生态已经全面转向Rack这一统一的Web服务器接口规范。如果你手头还有一套遗留的CGI脚本需要维护或迁移，理解CGI与Rack在架构层面的本质差异，是顺利完成转型的第一步。本文将从原理对比入手，逐步给出可落地的迁移方案。
CGI与Rack的核心差异
CGI的工作模式是“一请求一进程”：Web服务器（如Apache）每收到一个请求，就fork一个新进程来执行Ruby脚本，脚本从环境变量ENV中读取请求信息，把结果写到标准输出，进程随即退出。这种模式的优点是实现简单、与服务器解耦彻底，但每次请求都要重新启动Ruby解释器、加载数据库驱动和业务代码，开销极大，并发能力很差。
Rack则完全不同。它定义了一个极简的接口约定：一个Ruby对象只要能响应call方法，接收一个环境Hash并返回[status, headers, body]三元组，就是一个合法的Rack应用。应用常驻内存，由Rack服务器（Puma、Unicorn、Falcon等）托管，请求之间复用进程资源，性能可以提升一个数量级以上。更重要的是，Rack是Sinatra、Rails、Hanami等几乎所有现代Ruby Web框架的底层基石，迁移到Rack意味着自动接入整个现代生态。
简单概括两者关系：CGI把“请求”表示成环境变量和标准输入，把“响应”表示成标准输出；Rack把“请求”表示成一个结构化的env Hash，把“响应”表示成一个Ruby数组。迁移的本质，就是把脚本的输入输出逻辑映射到Rack的调用约定上。
从CGI脚本到Rack应用的迁移步骤
迁移工作可以分三步走：先梳理CGI脚本的输入处理，再改造输出逻辑，最后接入运行环境。下面用一个典型的CGI脚本做演示。
先看迁移前的CGI脚本，它读取表单参数、输出HTML页面：
#!/usr/bin/env ruby
require 'cgi'
cgi = CGI.new
name = cgi['name']
# 读取请求头
user_agent = ENV['HTTP_USER_AGENT']
# 输出响应头和内容
print cgi.header('type' => 'text/html')
puts "<html><body>"
puts "<h1>Hello, #{CGI.escapeHTML(name)}</h1>"
puts "</body></html>"
迁移到Rack后，同样的逻辑改写为一个响应call的对象。注意几个关键映射：CGI的ENV['QUERY_STRING']对应Rack env中的QUERY_STRING，表单参数统一通过Rack::Request解析，响应头不再用print输出，而是放进headers Hash：
require 'rack'
require 'rack/request'
class HelloApp
def call(env)
request = Rack::Request.new(env)
name = request.params['name'].to_s
body = <<~HTML
<html><body>
<h1>Hello, #{Rack::Utils.escape_html(name)}</h1>
</body></html>
HTML
[200, {'Content-Type' => 'text/html; charset=utf-8'},
[body]]
end
end
run HelloApp.new
第三步是部署方式的变化。CGI脚本放在服务器的cgi-bin目录下靠HTTP服务器直接调用，而Rack应用需要用Rack服务器运行，最简单的方式是写一个config.ru文件，然后执行rackup命令，或交给Puma托管：puma config.ru。生产环境通常再用Nginx做反向代理，把请求转发给本地的Rack服务器进程。
常见迁移陷阱与应对方案
第一个陷阱是编码问题。老CGI脚本常假设外部输入是特定编码，而Rack的env遵循RFC 3875，PATH_INFO等值是二进制编码的ASCII-8BIT字符串，拼接到UTF-8字符串里会报Encoding::CompatibilityError。正确做法是在使用前显式强制编码，或统一交给Rack::Utils与Rack::Request处理。
第二个陷阱是全局状态。CGI进程用完即弃，全局变量、类变量随便用也不会出问题；Rack应用常驻内存，多个请求共享同一批对象，全局可变状态会引发数据串扰和线程安全问题。迁移时应把请求相关的状态封装进局部变量或请求对象，把跨请求的状态交给数据库、缓存或会话存储。
第三个陷阱是输出习惯。CGI时代常见的print逐步输出、半路exit、直接重定向后不再返回等写法，在Rack里都不合法。Rack要求call必须完整返回三元组，重定向要返回3xx状态码并设置Location头，提前终止逻辑应改写为提前return三元组。会话管理也不再依赖Cookie手工解析，直接使用Rack::Session::Cookie中间件即可：
use Rack::Session::Cookie, key: 'myapp.session',
secret: 'change-me-in-production'
run HelloApp.new
迁移之后的进阶方向
完成基础迁移只是起点。Rack生态最有价值的能力是中间件链：日志、异常捕获、静态资源服务、限流等横切关注点都可以做成中间件按需叠加，用use语句声明即可，这是CGI架构完全无法提供的扩展方式。
如果业务继续增长，可以平滑升级到Sinatra这种轻量框架——Sinatra应用本身就是Rack应用，路由、模板、参数校验开箱即用；再往后如果需要ORM、迁移、完整MVC结构，可以进一步迁移到Rails。整个升级路径中，你写的Rack层代码和中间件全部可以复用，前期迁移的投入不会浪费。
最后建议在迁移前先补一套请求级别的集成测试，用Rack::Test模拟请求验证新旧实现输出一致，再灰度切换流量，这是保证老系统平稳过渡最有效的手段。