Rails中布尔字段1被解析为false的异常问题求助

从你的描述来看，这个问题的核心矛盾是：数据库中deleted字段存储的是1，但Rails读取后却返回false，而同类型的emailverified字段工作完全正常。结合你提供的代码，我认为最可能的原因是**after_initialize :set_uid回调意外覆盖了deleted属性的值**。

为什么会出现这个问题？ #

你的User模型中定义了after_initialize :set_uid回调，这个方法会在每个User实例初始化时（包括从数据库读取已有记录时）自动执行。如果set_uid方法里不小心加入了类似self.deleted = false的代码，那么不管数据库里存储的是什么值，实例化后的deleted属性都会被强制设为false。

这刚好能解释你遇到的所有异常现象：

• 执行User.where(deleted: 1)时，SQL语句正确匹配了deleted=1的记录，但实例化后deleted被回调改成了false；
• 测试用例中user_after_deletion.deleted始终为false，即使数据库里存的是1；
• emailverified字段不受影响，因为回调没有修改它。

排查与解决步骤 #

1. 检查set_uid方法的实现 #

打开你的User模型，找到set_uid方法，确认里面有没有修改deleted属性的代码。比如：

def set_uid
  # 假设这里有代码不小心设置了deleted
  self.deleted = false # 这行就是问题根源！
  self.uid = generate_uid # 你的正常业务逻辑
end

如果存在类似的代码，直接删除这行即可。

2. 验证数据库读取的原始值 #

在Rails控制台中执行以下命令，确认数据库中的原始值是否正确：

user = User.find(4)
# 读取数据库中的原始值，绕过模型的属性访问器
puts user.read_attribute(:deleted) # 正常应该返回1
puts user.deleted # 如果返回false，说明模型层有代码修改了这个值

如果read_attribute(:deleted)返回1，但user.deleted返回false，就坐实了是模型回调或自定义访问器修改了属性值。

3. 确认数据库字段与Schema匹配 #

检查db/schema.rb文件，确保deleted字段的定义是布尔类型：

create_table "users", force: :cascade do |t|
  # ... 其他字段
  t.boolean "deleted"
  t.boolean "emailverified"
  # ...
end

如果字段类型不对，可以重新运行迁移或手动修正（注意提前备份数据）。

4. 清除Rails缓存并重启服务器 #

有时候Rails会缓存模型的属性定义，重启服务器或执行以下命令清除缓存：

rails tmp:clear

额外建议 #

在使用after_initialize回调时要格外小心，因为它会在所有实例初始化时触发，包括从数据库加载记录的场景。如果set_uid方法只需要在创建新用户时执行，可以改用before_validation :set_uid, on: :create，避免影响已存在的记录。

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