Ruby on Rails软删除失效：已删除记录仍被查询包含

结合你使用的paranoia gem（软删除实现）和当前症状，以下是可能的原因及对应的排查/解决步骤：

1. Paranoia 默认作用域（Default Scope）失效 #

paranoia的核心是通过给模型添加默认作用域where(deleted_at: nil)过滤软删除记录，一旦这个作用域被破坏，所有默认查询都会包含已删除记录：

• 排查：打开app/models/submit.rb，确认是否存在acts_as_paranoid声明且未被注释/移除。如果模型自定义了default_scope，检查是否覆盖了paranoia的规则——比如自定义default_scope { where(status: 'active') }会直接替换paranoia的作用域，导致软删除过滤失效。
• 解决：若有自定义默认作用域，需合并paranoia的条件，示例：

  default_scope { where(status: 'active').where(deleted_at: nil) }
  # 或利用paranoia提供的方法合并
  default_scope { with_paranoid.default_scope }
  

  未自定义作用域时，可在Rails控制台执行Submit.default_scopes，查看输出是否包含deleted_at: nil的过滤条件。

2. 全局/局部查询被强制取消作用域 #

近期代码变更可能存在以下情况：

• 某处调用了Submit.unscoped（比如后台任务、交互逻辑中），若存在全局monkey patch或回调修改ActiveRecord::Relation的行为，可能导致默认作用域失效。
• 使用ActiveRecord::Base.unscoped包裹批量操作，影响了后续查询。
• 排查：搜索项目代码中的unscoped关键词，检查是否有针对Submit模型或全局的不当使用。在控制台测试Submit.count和Submit.with_deleted.count，若两者数值相同，说明默认作用域完全失效。
• 解决：移除不必要的unscoped调用，若必须使用，确保仅作用于单次查询（如Submit.unscoped.where(...)），而非全局修改。

3. Gem 兼容性冲突 #

你使用的paranoia 2.6.1发布于2022年，而Rails 7.0.4引入了部分ActiveRecord新特性，可能存在兼容性问题：

• 排查：查看Gemfile.lock，确认近期是否更新过paranoia或关联gem（如activemodel、activesupport）。在控制台执行Submit.acts_as_paranoid?，返回true说明paranoia已正确挂载到模型。
• 解决：尝试更新paranoia到兼容Rails 7的版本（目前最新稳定版为3.1.0），更新后重新测试查询是否恢复正常。注意更新前备份代码，避免兼容性问题。

4. Cancancan 权限规则干扰 #

如果Cancancan的权限定义中手动指定了查询条件，可能意外包含软删除记录：

• 排查：打开app/models/ability.rb，检查针对Submit的权限规则，比如是否有can :read, Submit, deleted_at: nil以外的写法——若直接写can :read, Submit，理论上会尊重模型默认作用域，但如果存在自定义scope或条件覆盖，可能失效。
• 解决：确保权限规则中明确排除软删除记录，或确认Cancancan未修改模型的查询作用域。

快速验证步骤 #

1. 启动Rails控制台：rails c
2. 执行Submit.count和Submit.with_deleted.count，对比数值差异
3. 执行Submit.where(deleted_at: nil).count，查看是否和预期的Submit.count一致
4. 执行Submit.acts_as_paranoid?，确认返回true

通过以上步骤可快速定位问题，再针对性修复。

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