HTTParty#lock覆盖ActiveRecord#lock导致悲观锁失效的解决方案问询

你的ActiveRecord模型类中直接引入了HTTParty模块，Ruby的方法查找逻辑中，混入模块的同名方法优先级高于父类继承的方法，因此HTTParty提供的lock类方法覆盖了ActiveRecord原本的悲观锁lock方法，导致调用报错。

以下方案按推荐优先级排序：

1. 拆分HTTParty逻辑到独立服务类（最推荐） #

HTTParty的定位是HTTP请求封装工具，不应该和ActiveRecord模型的业务逻辑耦合，你可以将所有依赖HTTParty的API请求逻辑抽离为独立的服务类，完全避免方法冲突，同时符合单一职责设计原则：

# 单独定义API请求服务类，不要写在ActiveRecord模型里
class UserApiClient
  include HTTParty
  base_uri "https://example.com/users"

  def self.fetch(id)
    get("/#{id}")
  end
end

# 原User模型不再引入HTTParty，可正常使用悲观锁
class User < ApplicationRecord
  # 其他模型逻辑
end

# 调用示例
User.lock.find(1) # 正常调用ActiveRecord的lock方法
user_api_data = UserApiClient.fetch(1) # 单独调用HTTP请求逻辑

2. 模型中显式还原lock方法指向ActiveRecord实现 #

如果确实有特殊需求必须在模型中引入HTTParty，可以在引入前备份原有lock方法，引入后重新覆盖回ActiveRecord的实现：

class User < ApplicationRecord
  # 引入HTTParty前先备份原ActiveRecord的lock类方法
  class << self
    alias_method :active_record_lock, :lock
  end

  include HTTParty # 此时HTTParty的lock会覆盖原有方法

  # 重新定义lock方法，指向备份的ActiveRecord实现
  class << self
    def lock(*args, &block)
      active_record_lock(*args, &block)
    end
  end

  # 其他模型逻辑
end

修改后User.lock.find(1)即可正常调用悲观锁逻辑，同时HTTParty的其他功能不受影响。

3. 使用替代的悲观锁写法规避冲突 #

如果只是临时需要使用悲观锁，不想改动类结构，也可以使用ActiveRecord提供的其他锁写法绕过冲突的lock类方法：

# 写法1：find方法传入lock参数
user = User.find(1, lock: true)

# 写法2：查询时指定lock选项
user = User.where(id: 1).lock(true).first

# 写法3：实例层面调用lock!方法
user = User.find(1)
user.lock! # 直接对实例加锁，不会触发类层面的冲突方法

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