在Django的CheckConstraint中使用timezone.now()是否会被缓存？

问题原因 #

你遇到的问题核心在于CheckConstraint 中的 timezone.now() 不是动态计算的：

• 当运行 makemigrations 时，Django 会执行 Q(my_date__lte=django.utils.timezone.now()) 表达式，此时 timezone.now() 会被立即求值，得到一个固定时间戳。
• 这个固定时间会被硬编码到迁移文件中，最终写入数据库的 CHECK 约束，变成类似 my_date <= '2024-05-20 12:00:00+00' 的静态规则。
• 而你在 form_valid 中设置的 obj.my_date = timezone.now() 是实时当前时间，必然晚于迁移时固化的固定时间，因此触发约束违反报错。

简单来说，这个时间不是被缓存，而是在迁移阶段就被永久固定到数据库约束里，不会每次检查都重新计算。

解决方案 #

要实现「my_date 不晚于当前时间」的动态约束，需要使用数据库原生的当前时间函数，而非 Python 层面的 timezone.now()。Django 提供了 Now() 函数对接数据库当前时间：

1. 导入 Now：

from django.db.models.functions import Now

2. 修改模型的 CheckConstraint：

class MyModel(models.Model):
    my_text = models.CharField(max_length=255)  # CharField 必须指定 max_length 参数
    my_date = models.DateTimeField()

    class Meta:
        constraints = [
            models.CheckConstraint(
                check=Q(my_date__lte=Now()),
                name='myconstraint'
            )
        ]

3. 重新生成并应用迁移：

python manage.py makemigrations
python manage.py migrate

修改后，数据库的 CHECK 约束会调用数据库原生当前时间函数（如 PostgreSQL 的 CURRENT_TIMESTAMP），每次插入或更新数据时都会实时计算当前时间，与 my_date 对比，不会再出现时间差导致的约束违反。

补充说明 #

• 你调试中看到的 my_date 是正确的 UTC 时间，但数据库约束里的时间是迁移时刻的固定值，两者对比自然不满足 <= 条件。
• 注意：CharField 必须指定 max_length，否则 Django 会抛出验证错误。

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