为何将已在Gemfile.lock中的gem加入Gemfile可解决railtie问题

问题1：本场景下，为什么在Gemfile中添加gem可以解决railtie相关问题？ #

Rails启动时的gem初始化逻辑是核心原因：Rails只会自动加载直接声明在Gemfile中的gem的Railtie/Engine初始化逻辑，对于依赖的依赖（也就是间接依赖），默认不会主动执行其Railtie代码。
你遇到的场景里，omniauth gem本身带有Railtie，会自动完成中间件注入、全局默认配置等初始化操作，其中就包含和CSRF校验相关的配置逻辑。此前omniauth是omniauth-oauth2的间接依赖，Rails没有触发它的Railtie执行，相关初始化配置缺失，才会出现对应报错。当你把omniauth显式加入Gemfile后，Rails启动时会主动加载执行它的Railtie，配置补全后问题就解决了。

问题2：已经在Gemfile.lock中存在的gem，添加到Gemfile后运行Bundler，Rails会如何解读这一变更？ #

首先从Bundler层面看：如果该gem已经满足现有依赖的版本约束，bundle install不会修改版本、也不会重复安装，只会在内部把这个gem的标记从「间接依赖」改成「直接依赖」，Gemfile.lock里只会更新依赖标记，不会有其他变更。
从Rails层面看，二者的核心差异就是初始化逻辑的执行：

• 间接依赖的gem：只有被其他显式依赖的gem主动require时才会加载代码，其自带的Railtie、初始化脚本不会被Rails自动执行
• 显式声明在Gemfile中的gem：Rails启动时会主动require其主文件，并且自动执行其附带的Railtie、Engine初始化逻辑

举个实际例子，如果你用的某个gem依赖gem_foo，gem_foo自带的Railtie要给Rails加一个全局路由，只要你没把gem_foo写在Gemfile里，这个路由就不会被自动注入，哪怕它已经被安装在本地、存在于Gemfile.lock中也没用。

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