Rails 4.2升级至5.2后调用AR的changed?/changes方法触发栈溢出错误

我之前升级Rails版本时也碰到过几乎一模一样的栈溢出问题，结合你的情况，给你几个实用的排查方向：

• 检查自定义setter或attribute_will_change!的使用
  Rails 5.x对ActiveRecord的属性变更追踪逻辑做了不少内部调整，4.2里手动调用attribute_will_change!的写法在5.2里可能触发无限递归。比如如果你的模型里有类似这样的代码：

  def title=(value)
    self[:title] = value.strip
    attribute_will_change!(:title)
  end
  

  在Rails 5.2中，直接赋值self[:title]已经会自动触发变更追踪，手动再调用attribute_will_change!就会导致重复触发变更检查，最终栈溢出。可以尝试去掉手动的attribute_will_change!调用，看看问题是否解决。

• 排查第三方gem的兼容性
  很多追踪属性变更、序列化的旧gem在Rails 5.2下可能存在兼容性问题，比如paper_trail、audited这类审计gem，或者一些自定义的ActiveRecord扩展。你可以尝试临时注释掉Gemfile里的非核心gem，逐个恢复并测试，找到哪个gem导致了冲突，然后升级该gem到兼容5.2的版本。

• 检查模型回调中的循环触发
  如果你的模型里有after_initialize、before_validation这类回调，里面有修改属性的操作，同时又间接触发了changed?或changes的调用，就可能形成循环递归。比如在after_initialize里给某个属性设置默认值，而这个操作触发了回调，回调里又检查变更状态，无限循环下去。可以临时禁用这些回调，确认是否还会报错。

• 开启详细调试日志定位递归源头
  虽然错误提示是stack level too deep，但通过详细的调用栈可以找到重复执行的方法。在config/environments/development.rb里添加以下配置：

  config.log_level = :debug
  config.active_record.logger = Logger.new(STDOUT)
  

  重新触发错误后，查看控制台输出的完整调用栈，找到反复出现的方法，就能精准定位问题所在。

• 排查是否有重写changed?/changes的代码
  即使你没修改模型代码，也可能存在混入的concern或者模块重写了这些方法，在Rails 5.2的新逻辑下导致递归。可以全局搜索项目中的def changed?或def changes，看看是否有自定义实现，检查这些实现是否和新版本的ActiveRecord方法冲突。

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