Rails API的JWT Token认证在开发环境正常但生产环境异常

我来帮你梳理一下Rails开发模式和生产模式的核心差异，结合你遇到的JWT认证401问题，这些差异很可能是问题的根源：

1. 密钥与敏感配置的处理差异 #

生产模式下Rails对敏感配置的要求更严格：

• 开发模式可能直接使用config/secrets.yml里未加密的默认密钥，甚至允许你在代码里临时硬写密钥（虽然不推荐）；但生产模式必须使用加密的credentials.yml.enc或者服务器环境变量来存储密钥。
• 你的JWT认证依赖签名/验证密钥，如果生产环境的secret_key_base或者自定义JWT密钥和开发环境不一致，Token验证会直接失败，返回401。这是此类问题最常见的原因之一。

2. 中间件与安全策略的差异 #

生产模式会启用更多安全相关的中间件，可能影响Token的传递和验证：

• 比如config.force_ssl如果在生产环境开启，而你的请求没有通过HTTPS，可能导致Authorization头丢失或被篡改；
• CORS配置在生产模式下会更严格，如果前端请求的Origin不在允许列表里，浏览器会拦截Authorization头的传递，服务器拿不到Token就会直接返回401；
• 部分安全中间件（比如Rack::Attack）可能会过滤异常请求，如果你生产环境的请求频率限制或规则设置不当，也可能触发拦截。

3. 缓存与代码加载的差异 #

• 缓存机制：生产模式默认启用缓存，而开发模式缓存是关闭的。如果你的认证逻辑依赖缓存（比如缓存Token的有效性），生产环境缓存配置错误（比如Redis连接失败）会导致无法正确验证Token状态。
• 代码预加载：生产模式会在启动时预加载所有代码，如果你部署后修改了JWT认证相关的代码（比如AuthenticateRequest concern）但没重启服务器，旧代码会继续运行，可能导致逻辑异常。

4. 日志与调试信息的差异 #

开发模式会输出详细的请求日志、中间件执行过程、Token解析细节；但生产模式默认日志级别是:info，只会记录关键信息。你可以临时修改config/environments/production.rb里的config.log_level = :debug，重启服务器后查看日志，就能知道authenticate_request过滤器具体在哪个环节失败了——比如Token提取失败、签名验证错误、找不到对应用户等。

针对你的401错误的排查步骤 #

结合这些差异，你可以按以下步骤排查：

• 先确认生产环境的JWT密钥和开发环境一致：检查config/initializers/jwt.rb里的密钥配置，确保生产环境用的是和开发相同的密钥（比如通过环境变量传递）；
• 临时开启生产模式的debug日志，查看authenticate_request的执行细节；
• 测试生产环境生成的Token：用JWT.decode(token, secret, true, algorithm: 'HS256')手动验证，看是否能正常解析出用户信息；
• 检查CORS配置：确保生产环境的config/initializers/cors.rb允许前端请求的Origin，并且允许携带Authorization头；
• 确认中间件顺序：检查config/application.rb里的中间件列表，确保AuthenticateRequest相关的过滤器在正确的位置，没有被其他中间件拦截。

内容的提问来源于stack exchange，提问作者Bastian