求助：ArgumentError报错——Api::V1已从模块树移除但仍活跃

我之前也踩过一模一样的坑！这种首次运行必崩、重新加载就正常的问题真的太闹心了，尤其在开发API的时候，每次启动都要多折腾一遍。结合我自己的排查经验和社区里的常见解法，给你整理几个方向：

1. 检查初始化阶段的代码加载顺序 #

这个是最常见的原因！如果你的config/initializers目录下的代码，在Rails完成自动加载之前就直接引用了控制器（比如ApplicationController）、模型这类类，就会导致旧的类实例留在内存里，后续Rails自动加载时就会触发模块树冲突。

举个例子，如果你在初始化器里写了：

# 错误示范：初始化阶段直接实例化控制器
auth_service = AuthService.new(ApplicationController.new)

这时候Rails还没完成控制器的加载流程，后续自动加载会生成新的ApplicationController类，旧的实例就变成了“被移除但仍活跃”的状态。

解决办法：把这类需要引用业务类的初始化逻辑，移到after_initialize回调里，确保Rails已经完成了所有类的加载：

# 正确写法：在after_initialize里执行
Rails.application.config.after_initialize do
  auth_service = AuthService.new(ApplicationController.new)
end

2. 排查Spring预加载器的缓存问题 #

Rails的Spring预加载器为了加快启动速度，会缓存一些类的实例，但有时候缓存会和代码更新冲突，导致首次启动时出现这个错误。

解决办法：

• 先手动重启Spring：在终端运行 spring stop，然后重新启动你的应用，看看问题是否消失。
• 如果频繁出现，可以试试在开发环境临时禁用Spring：在config/spring.rb里添加 Spring.enabled = false，验证是不是Spring的锅。

3. 检查动态常量定义的代码 #

如果你的API里有用到const_set、class_eval这类动态定义常量/类的代码，或者某些第三方gem在做类似操作，可能会导致旧的模块实例没被正确清理，触发错误。

解决办法：

• 排查代码中动态定义类的逻辑，确保在开发环境热重载时，旧的常量能被正确卸载。
• 开发环境可以临时把config.cache_classes设为true（在config/environments/development.rb里），虽然会失去热重载功能，但能验证是不是自动加载和动态常量的冲突问题。

4. 排查第三方gem的兼容性 #

有些gem（比如认证类、序列化类的gem）可能会在初始化阶段就引用你的控制器或模型类，打乱了Rails的自动加载顺序，导致冲突。

解决办法：

• 回忆最近新增的gem，逐个禁用试试，找到引发问题的那个gem。
• 查看该gem的官方文档，有没有针对Rails自动加载的配置项，或者尝试升级到最新版本，看是否修复了兼容性问题。

我当时就是把初始化器里的代码移到after_initialize里就彻底解决了这个问题，你可以先从这个方向入手排查！

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