Ruby元编程实现角色鉴权DSL时include重写方法问题求解

这个需求完全可以实现，你之前方案失效的核心原因是调用auth时就直接重写了目标方法，此时类中还未定义业务侧的同名方法，后续编写的def index?会直接覆盖掉auth生成的包装逻辑，自然无法通过super调用到预期的原方法。

你当前的策略类写法：

class UserPolicy < ApplicationPolicy
  def index?
    user.admin?
  end
end

期望实现的DSL调用形式：

auth :index?, roles: ['admin:all', 'admin:users:view']

预期逻辑：先校验当前用户是否持有配置中指定的任意角色，校验通过后再执行原方法内的业务判断。

核心思路是不要在调用auth时立刻重写方法，改为通过Ruby的method_added钩子延迟包装：等业务方法真正定义完成后，再替换为带权限校验的包装逻辑，从根本上避免方法定义顺序导致的覆盖问题。

完整的Concern实现代码如下：

module RoleBasedAuth
  extend ActiveSupport::Concern

  included do
    class_attribute :_role_auth_rules, default: {}
  end

  class_methods do
    def auth(method_name, roles:)
      # 仅存储权限配置，不立刻修改方法
      self._role_auth_rules = _role_auth_rules.merge(method_name.to_sym => roles)
    end

    def method_added(method_name)
      super
      # 刚定义的方法没有配置权限规则就直接跳过
      return unless _role_auth_rules.key?(method_name)

      # 取出配置，同时避免后续重写方法时触发递归
      required_roles = _role_auth_rules.delete(method_name)
      # 持有原始业务方法的引用
      original_method = instance_method(method_name)

      # 定义带权限校验的包装方法
      define_method(method_name) do
        role_check_passed = required_roles.any? { |role| user.roles.include?(role) }
        role_check_passed && original_method.bind_call(self)
      end
    end
  end
end

该实现完全兼容你预期的代码书写顺序，不需要调整业务策略类的结构：

class UserPolicy < ApplicationPolicy
  include RoleBasedAuth
  
  auth :index?, roles: ['admin:all', 'admin:users:view']

  def index?
    user.admin?
  end
end

• auth方法仅做配置持久化，不会提前生成包装方法，不会被后续定义的业务方法覆盖
• method_added是Ruby原生的类钩子，每次类中新增实例方法时会自动触发，刚好可以捕获业务方法定义完成的时机
• 包装前先通过instance_method拿到原始方法的引用，重写后通过bind_call绑定当前实例执行，不依赖super的方法查找链，稳定性更高
• 执行顺序完全符合预期：先做角色白名单校验，校验通过才会执行原方法内的业务逻辑
• 后续如果需要支持单方法叠加多套权限规则、批量给多个方法加权限，只需要调整配置存储结构和合并逻辑即可，扩展性良好。

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