Rails生产环境Sidekiq任务触发自动加载问题及配置咨询
多线程竞态导致的死锁
Sidekiq是多线程运行环境，而Rails 5.2的自动加载机制在多线程场景下存在线程安全缺陷。当多个Sidekiq线程同时触发const_missing去加载QueryBuilder模块时，会出现文件加载竞态冲突：一个线程正在读取解析query_builder.rb文件，另一个线程也尝试加载同一文件，导致线程互相阻塞，最终表现为任务长时间挂起。
而Rails控制台是单线程环境，不会触发这类竞态冲突，所以代码执行速度正常。
自动加载配置未生效的潜在原因
尽管你已经将lib/mixins加入eager_load_paths和autoload_paths，但生产环境下eager_load可能未正确触发：
- Sidekiq启动时未指定生产环境（如未设置
RAILS_ENV=production），导致config.eager_load = true未生效 - 部署时存在旧代码缓存，未及时清除
- 虽然文件名符合约定，但Rails自动加载机制可能未递归扫描到
lib/mixins目录（通常推荐直接添加lib根目录而非子目录）
1. 手动预加载模块
在Sidekiq初始化文件（如config/initializers/sidekiq.rb）中手动引入模块，避免多线程下的自动加载竞态：
require "#{Rails.root}/lib/mixins/query_builder"
2. 确保Sidekiq以生产环境启动
启动Sidekiq时明确指定环境，保证eager_load在启动阶段预加载所有指定路径的文件：
RAILS_ENV=production bundle exec sidekiq
3. 修正自动加载路径配置
修改config/application.rb，直接添加lib根目录到加载路径（Rails会递归扫描子目录）：
config.autoload_paths << "#{Rails.root}/lib" config.eager_load_paths << "#{Rails.root}/lib"
4. 清除代码缓存
部署时执行缓存清理命令，避免旧缓存影响自动加载：
RAILS_ENV=production rails tmp:cache:clear
将QueryBuilder改为可实例化对象确实更合适，核心原因：
- 线程安全：实例化对象的状态是线程隔离的，不会出现多线程共享模块类变量/方法的冲突
- 可测试性：实例化对象更容易通过依赖注入完成单元测试，无需处理模块全局状态
- 灵活性：可以根据不同业务场景创建不同配置的实例，而模块
extend是静态绑定，无法动态调整
如果模块仅提供查询构建的工具方法、无全局共享状态，改为实例化对象是更符合现代Ruby/Rails开发的实践。
核心概念
autoload_paths：Rails运行时找不到常量时，会在这些路径下查找对应文件并自动加载，多用于开发环境eager_load_paths：Rails启动时预加载这些路径下所有符合命名约定的文件，多用于生产环境，避免运行时加载开销
分环境配置方式
开发环境
仅配置autoload_paths，保持config.eager_load = false（默认值）：
# config/environments/development.rb config.autoload_paths << "#{Rails.root}/lib"
生产环境
同时配置eager_load_paths并开启eager_load：
# config/environments/production.rb config.eager_load = true config.eager_load_paths << "#{Rails.root}/lib"
注意：路径建议使用Rails.root拼接，避免硬编码绝对路径；Rails会自动去重重复添加的路径，无需重复配置。
为Rails 6+升级做准备
Rails 6+默认使用Zeitwerk作为自动加载器，替代了旧的classic模式，升级前需注意：
- 严格遵循文件命名约定：模块
Foo::Bar必须对应文件foo/bar.rb - 在
config/application.rb中设置config.load_defaults 6.0开启Zeitwerk - 对于
lib目录，可使用config.autoload_lib(ignore: %w[tasks generators])自动加载非任务、非生成器的文件，或手动添加config.autoload_paths << Rails.root.join('lib')
内容的提问来源于stack exchange，提问作者RubyRedGrapefruit
